简介面向个人站长与Web开发者的ASP源码方案核心解决手机端拍照上传需反复确认的痛点适用于移动巡检、现场取证、随手记等场景。系统仅需两个ASP页面index.asp负责调起摄像头拍照并自动上传无需二次确认即可连续拍传view.asp用于后台管理源码第7行预留了密码修改位。同时借助JS二维码库自动生成访问入口方便手机扫码或收藏直达。压缩包共5个文件包括2个ASP页面、1个JS二维码库、1张示例图片与1份说明文档整体体积仅1.09MB结构精简、易于部署调试。由于需调用手机摄像头部署要求开启SSL并具备公网访问能力适合有一定IIS基础的中高级开发者。已有28人学习包含可直接运行的源码与关键逻辑注释可快速掌握二维码生成、拍照无确认上传、后台管理等完整实现思路并根据自身项目扩展功能。1. 手机拍照无确认连续上传系统解决的不是“拍照”而是“传得快”做外勤巡检、保险定损、工地验收、门店拜访这类场景的同学多半遇到过同一个痛点现场人员用手机拍了一堆照片回到有网的地方再一张张点“上传”经常漏传、传错、传一半。你催他他还不耐烦。所谓的“手机拍照无确认连续上传系统ASP源码”本质就是把这套“先拍后传”改成“拍完即传、连拍连传”——前端H5页面调用手机摄像头拍完一张自动上传不需要再点“确认上传”按钮拍下一张的时候上一张可能已经在服务器落盘了。服务端用ASP技术栈经典ASP或ASP.NET均可接收、命名、落库统一塞进一套存量管理系统里。适合谁适合已经在用Windows服务器、不想为一个小功能引入Java/PHP新服务的团队也适合专门研究ASP源码来做二次开发的技术型读者。这篇文章会把服务端接收、前端连续上传队列、IIS配置和真正上线时最容易翻车的坑按我实际做过的方式给你拆开。2. 无确认连续上传的底层逻辑从“选文件”到“自动入列”2.1 拍照无确认是怎么实现的capture 属性与微信 JS-SDK 的取舍先说“无确认”到底指什么。浏览器出于权限和安全考虑不可能让网页在用户完全不知情的情况下调起相机咔咔连拍——那个叫间谍软件不是正常业务系统。实际业务里说的“无确认”是指用户只需要拍一次照或者选一次照片系统自动开始上传不再弹一个“确认上传”的二次确认框。这是两个不同的确认层级拍照动作本身需要用户参与但“要不要发送”这个确认被去掉了。HTML5 的input typefile加上 capture 属性是普通浏览器里的标准做法input typefile idcameraInput acceptimage/* captureenvironment /captureenvironment 在 Android 上会直接调起后置摄像头iOS 的 Safari 表现略有差异它可能仍然先弹照片选择器。想要更可控的拍照体验常见做法是接入微信 JS-SDK 的 chooseImage拍照后拿到的 localIds 可以直接作为 img 预览再通过 uploadImage 接口传到微信临时素材最后推给自己的服务器。但微信通道会多一跳且只能存三天长期保存还是得靠自己的接收接口。我给现场团队做的时候默认给普通浏览器 Web 页走input capture 隐藏表单给企业微信内嵌页面走 JS-SDK两套方案的上传提交逻辑共用同一个队列。这里有个容易想偏的地方无确认并不等于无进度。用户拍完照页面要立刻给出“上传中”的视觉反馈否则用户以为没拍上又连拍好几张造成重复数据。所以前端队列的每个条目都要有状态拍摄完成、上传中、已上传、上传失败可重试。状态机越简单现场越不容易乱。2.2 连续上传的队列模型串行队列比并行更稳连续上传最容易踩的坑是一上来就写“循环上传”// 错误示范把选中文件全部并行发出去 for (let file of fileList) { upload(file); }手机浏览器尤其是安卓 WebView并发发三五个大图请求轻则排队阻塞重则直接把 WebView 撑挂。单张动辄 3MB 到 8MB 的现场照片并行上传会迅速打满带宽还会让服务端 ASP 脚本在写磁盘时发生并发争用。我做这类系统前端永远是一个串行队列同一时刻只传一张上一张完成或失败后才从队列里取出下一张。class UploadQueue { constructor() { this.list []; this.busy false; this.maxRetry 2; } push(file, onProgress, onDone, onFail) { this.list.push({ file, onProgress, onDone, onFail, retry: 0 }); this.pump(); } pump() { if (this.busy || this.list.length 0) return; const item this.list.shift(); this.busy true; this.uploadOne(item) .then((resp) { item.onDone(resp); this.busy false; this.pump(); }) .catch((err) { if (item.retry this.maxRetry) { item.retry 1; this.list.unshift(item); // 放回队头重试 } else { item.onFail(err); } this.busy false; this.pump(); }); } uploadOne(item) { const formData new FormData(); formData.append(file, item.file); return new Promise((resolve, reject) { const xhr new XMLHttpRequest(); xhr.open(POST, /upload/upload.asp, true); xhr.upload.onprogress (e) { if (e.lengthComputable) item.onProgress(Math.round((e.loaded / e.total) * 100)); }; xhr.onload () { if (xhr.status 200) resolve(xhr.responseText); else reject(new Error(HTTP xhr.status)); }; xhr.onerror () reject(new Error(network error)); xhr.send(formData); }); } }这段代码里三个参数决定连续上传的体感maxRetry 设为 2是让弱网下有挽回余地但不至于无限重试拖住后面队列。失败任务unshift回队头而不是push到队尾因为越早重试越容易成功丢到最后反而忘了这张没传上去。串行pump()每次只推一个任务避免并发把服务端 ASP 同时处理多个二进制流的局面搞乱。现场验证时我会在 DevTools 的 Network 面板里把网络模拟成 Fast 3G连续拍五张看请求是不是一张接一张跑的。如果你发现浏览器同时发起了多个请求说明队列没锁住。2.3 上传协议与后端语言的适配multipart 是唯一现实选择无确认连续上传本质上就是持续往服务器推 multipart/form-data 数据包。每条上传请求里包含一张图片的二进制内容附带一个文件名、拍摄时间、经纬度如果前端拿得到、设备号。ASP 端接到的就是一个标准的 HTTP POST 请求。有人问“asp 能否搭配 mysql”能完全能。经典 ASP 通过 ADODB 连接 MySQL 的 ODBC 驱动即可ASP.NET 则用 MySqlConnector 或 Oracle 官方驱动。图片本体不要进数据库存磁盘库里只落文件的相对路径、拍摄时间、上传时间、设备编号和上传状态。这样连续上传时数据库的压力只是多条 INSERT而不是把大二进制塞进 BLOB 字段来回搬运后者在 MySQL 的 packet 限制下很容易在连续上传中途翻车。设计协议的时候前后端约定一个轻量 JSON 返回结构。上传成功返回{code:0,path:/uploads/2025/06/xxx.jpg}失败返回{code:1,msg:磁盘写入失败}。前端 onProgress 只管进度条onDone 里把后端返回的 path 填进当前照片的预览角标上。这些约定的字段后端 ASP 接收完文件后一帧一帧拼出来就行。3. ASP 源码的服务端骨架IIS、接收函数与存储选型3.1 win11 配置 IIS ASP 的最小操作清单“win11配置iis asp”是现在捯饬 ASP 源码的人高频遇到的第一个门槛。Win11 默认没装 IIS更没开 ASP 功能得手动启用。图形界面装或者命令行装都行命令行更快# 以管理员身份运行 PowerShell dism /online /enable-feature /featurename:IIS-WebServerRole /all dism /online /enable-feature /featurename:IIS-ASP /all装完 IIS 后打开“Internet Information Services (IIS) 管理器”在左侧“连接”里选中站点双击中间“ASP”图标把“启用父路径”设为 True。很多老的 ASP 代码里用了../相对路径不开启这一项直接 500。然后在“处理程序映射”里确认 aspClassic 被启用。最后在 C 盘留一个可写目录作为上传落点比如C:\uploads并给IIS_IUSRS加读写权限。右键目录 - 属性 - 安全 - 编辑 - 添加 - 输入IIS_IUSRS赋予“修改”权限。这个权限没给对的症状是前端上传报 200但 ASP 内部写入失败返回的 JSON 里 code 是 1。3.2 ASP 接收上传文件的经典代码BinaryRead 与组件方案经典 ASP 接收 multipart 图片官方没有直接的 Request.Form 读取二进制的办法因为Request.Form只解析文本字段图片的二进制部分会被截断。最常用的两条路第一装第三方上传组件比如 AspUpload、SA-FileUp第二用Request.BinaryRead手动解析整个请求体。组件省事但要在服务器装 dll、注册组件纯 ASP 解析不依赖环境但代码长、边界情况多。我一般建议生产上用组件学习和调试用纯 ASP 解析足矣。下面是纯 ASP 接收单张小图片的最小实现% Option Explicit Dim RequestBin, i, boundary, pos, contentDisposition, filename, fileData, finalPath 1. 读入请求体全部字节 RequestBin Request.BinaryRead(Request.TotalBytes) 2. 从 Content-Type 里取 boundary 分隔串 boundary Mid(Request.ServerVariables(CONTENT_TYPE), _ InStr(Request.ServerVariables(CONTENT_TYPE), boundary) 9) 3. 把字节流转成文本只是为了定位字段边界对图片本体用字节操作 Dim binStr binStr BinaryToString(RequestBin) pos InStr(binStr, filename) if pos 0 Then Dim startFile startFile InStr(pos, binStr, vbCrLf vbCrLf) 4 Dim endMarker endMarker InStr(startFile, binStr, -- boundary --) if endMarker 0 Then endMarker InStr(startFile, binStr, -- boundary) End If If endMarker 0 Then Response.Write 非法请求 Response.End End If 4. 截取二进制图片数据 Dim lenData lenData endMarker - startFile fileData MidB(RequestBin, startFile, lenData) 5. 生成唯一文件名落盘 Dim fso, savePath savePath Server.MapPath(/uploads/) GenerateFileName() .jpg Set fso CreateObject(Scripting.FileSystemObject) Dim fs Set fs fso.CreateTextFile(savePath, True) fs.Write fileData fs.Close Response.ContentType application/json Response.Write {code:0,path: savePath } Else Response.Write {code:1,msg:未发现文件字段} End If Function GenerateFileName() Dim r r Year(Now()) Right( Month(Now()), 2) Right( Day(Now()), 2) _ _ Right( Hour(Now()), 2) Right( Minute(Now()), 2) _ Right( Second(Now()), 2) _ Int(Rnd * 100000) GenerateFileName r End Function Function BinaryToString(binValue) Dim cl1, cl2, cl3, pl1, pl2, pl3 Dim result result Dim k For k 1 To LenB(binValue) Step 3 cl1 AscB(MidB(binValue, k, 1)) cl2 AscB(MidB(binValue, k 1, 1)) cl3 AscB(MidB(binValue, k 2, 1)) result result Chr(cl1) If cl2 0 Then result result Chr(cl2) If cl3 0 Then result result Chr(cl3) Next BinaryToString result End Function %逻辑说明这个脚本先取Request.TotalBytes拿到请求体完整长度用BinaryRead全部读入内存。找 boundary 的目的是在二进制流里定位文件内容的起止位置。filename出现的位置之后后面隔一个空行就是文件二进制正文的开始再往后到下一个 boundary 就是结束。中间截出来的MidB(RequestBin, startFile, lenData)就是完整图片数据。参数说明Request.ServerVariables(CONTENT_TYPE)拿到的头信息形如multipart/form-data; boundary----WebKitFormBoundaryxxx从中切 boundary 串时注意索引别差一个字符切错会导致整个解析失败。startFile和endMarker这两个位置的定位是血泪经验少算一个回车换行写出来的文件会多一个字节或少几个字节图片就可能打不开。如果你不想折腾解析直接装 AspUpload 组件代码缩成五行Dim upload, file Set upload Server.CreateObject(Persits.Upload) upload.OverwriteFiles False Set file upload.Files(file) file.SaveAs Server.MapPath(/uploads/) GenerateFileName() .jpg3.3 存储落点MySQL 存路径、磁盘存图片的常见做法连续上传系统里数据库表结构要简单到不能再简单。我一般建一个upload_log表CREATE TABLE upload_log ( id INT AUTO_INCREMENT PRIMARY KEY, device_no VARCHAR(64) DEFAULT , latitude DECIMAL(10,6) DEFAULT 0, longitude DECIMAL(10,6) DEFAULT 0, file_path VARCHAR(255) NOT NULL, file_size INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段解释device_no 记录是哪台手机传的latitude/longitude 记录拍照位置file_size 用于回传后的核对create_time 按数据库时间而不是相信手机本地时间——现场手机时间经常不准统一用服务器时间做排序和审计。ASP 连 MySQL 的连接串经典写法是Dim conn Set conn Server.CreateObject(ADODB.Connection) conn.Open Driver{MySQL ODBC 8.0 Unicode Driver};Server127.0.0.1;Databaseupload_db;Userroot;Passwordyourpass;Option3Option3是 MyODBC 里的常用配置表示启用客户端多语句等行为不加有时会出现中文乱码或者连接不稳定。这里也说明一个点如果客户只有 ASP 环境没有 PHP/JavaMySQL 完全可以用前提是你把 MySQL 的 ODBC 驱动装好64 位 IIS 就要装 64 位驱动别装岔了。4. 可复用的前端源码拍照到连续上传的完整闭环4.1 HTML 与摄像头交互input capture 的权限边界完整的页面只有三个区域拍摄按钮、预览列表、上传进度条区域。核心 HTML 部分如下div idcameraArea button idbtnShoot拍摄照片/button input typefile idcameraInput acceptimage/* captureenvironment styledisplay:none / /div ul idpreviewList/ul div iduploadStatus styledisplay:none;正在上传 0 张成功 0 张/div按钮点击触发隐藏的 file input 打开相机document.getElementById(btnShoot).addEventListener(click, function() { document.getElementById(cameraInput).click(); });这里注意一点acceptimage/*和capture属性同时写iOS 上有些版本会退化为照片选择器而不是相机想要强制相机试capturecamera但新版本 Safari 对camera的支持反而收紧了所以兼容写法还是environment为主业务上接受用户从相册选历史照片也算合理行为。关键是不能在用户没点按钮时主动input.click()浏览器会直接拦掉。4.2 JavaScript 上传队列源码连拍连传的前端闭环拍照完成触发 change 事件后立即把 File 对象加入上传队列同时渲染预览。document.getElementById(cameraInput).addEventListener(change, function(e) { const files e.target.files; for (let i 0; i files.length; i) { const file files[i]; // 文件类型只收图片大小限制 10MB if (!file.type.startsWith(image/)) continue; if (file.size 10 * 1024 * 1024) { alert(单张超过10MB请压缩后再传); continue; } // 先展示本地预览 const previewItem document.createElement(li); const img document.createElement(img); img.src URL.createObjectURL(file); img.width 100; const statusSpan document.createElement(span); statusSpan.className status; statusSpan.innerText 等待上传; previewItem.appendChild(img); previewItem.appendChild(statusSpan); document.getElementById(previewList).appendChild(previewItem); // 入队 queue.push(file, function(pct) { statusSpan.innerText 上传中 pct %; }, function(resp) { statusSpan.innerText 已上传 resp; updateGlobalStatus(); }, function(err) { statusSpan.innerText 失败点击重试; // 给该条记录绑定重试点击 previewItem.onclick function() { queue.push(file, statusSpan, arguments.callee.caller, window.console.error); }; } ); } // 清空 input 值保证同一张照片连续选择多次时 change 事件不失效 e.target.value ; });第二等说明e.target.value 这行很容易漏。如果不重置 input 的 value用户连拍两张同样文件名的照片很多安卓相册会生成相同文件名第二次触发不了 change照片就不会进入上传队列。重置 value 是最简单也最关键的一行。在这个循环里预览图用URL.createObjectURL生成临时地址不上传完成前不要 revoke否则预览图会裂。4.3 与 ASP 后端的约定文件名与字段名的对账前端 FormData 里 append 的字段名后端 ASP 组件里读的 Files(file) 或者纯解析里找的 filename 必须对得上。我统一约定字段名就叫file后端返回 JSON 里的 path 是相对路径。前端拿到 path 后在全部上传完成时把这次任务的所有 path 集合 POST 给一个finish.asp由它把整批上传任务标记为“已提交”。这样连续上传哪怕中途断掉服务端也知道哪些图片孤零零落盘了没有归队。async function finishBatch(paths) { const resp await fetch(/upload/finish.asp, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ taskId: currentTaskId, paths: paths }) }); const json await resp.json(); if (json.code 0) { alert(本次共上传 paths.length 张全部入库); } }这个 finish 接口存在的意义是上传是逐张瞬时动作业务上的“一批照片”需要有收口动作。没有它你永远不知道对方到底传完没传完。5. 连续上传上线避坑六个我在现场踩过的真实大坑5.1 IIS 默认请求长度限制照片超过 2MB 被静默拦截现象前端传小图一切正常传超过 2MB 的手机原图请求发出去服务端返回 404 或 400ASP 代码根本没执行。原因IIS 的maxAllowedContentLength默认是 30000000 字节看起来不小但 ASP 的Request.BinaryRead还会受 ASP 脚本自身的AspMaxRequestEntityAllowed限制经典 ASP 默认值是 204800 字节也就是 200KB。超过 200KB请求直接被 IIS 掐断。解决在 IIS 管理器里选择站点双击“ASP”在“限制属性”里把“最大请求实体主体限制”调大或者直接改 C:\Windows\System32\inetsrv\config\applicationHost.configconfiguration system.webServer asp limits maxRequestEntityAllowed209715200 / /asp security requestFiltering requestLimits maxAllowedContentLength209715200 / /requestFiltering /security /system.webServer /configuration两个节点都得改上面的管 ASP 解析的请求体上限下面的管 IIS 请求筛选器。改完重启站点单张 200MB 以内都能进 ASP。5.2 写入目录权限不足IIS_IUSRS 写不进去现象前端上传请求返回 200但 ASP 返回 JSON 里是 code1msg磁盘写入失败。去服务器看 IIS 日志也没有 500。原因上传目录没给 IIS 工作进程账户写权限。IIS 经典模式跑在 IUSR 账户下IIS 6.0/7.5 之后是 IIS_IUSRS 组。解决# 管理员 PowerShell 给上传目录授权 icacls C:\uploads /grant IIS_IUSRS:(OI)(CI)(M) /T icacls C:\uploads /grant IUSR:(OI)(CI)(M) /T参数说明(OI)表示文件对象继承(CI)表示目录继承(M)是修改权限。不加/T只改顶层目录子目录不会继承。改完最好把 IIS 进程回收一次iisreset /restart。5.3 文件重名与后传覆盖先传现象现场两个人同时用同一台手机或同一批次设备上传后传的照片把先传的同名照片覆盖了。或者 WebView 在弱网下重试时同名的旧文件覆盖了新文件。原因文件名用了时间戳到秒同一秒内两张照片同名或者前端重试时带了相同文件名。解决后端命名必须加随机成分和请求序号。Function GenerateFileName() Randomize Dim t t Year(Now()) Right(0 Month(Now()), 2) Right(0 Day(Now()), 2) _ _ Right(0 Hour(Now()), 2) Right(0 Minute(Now()), 2) _ Right(0 Second(Now()), 2) _ Int(Rnd * 89999) 10000 GenerateFileName t End FunctionInt(Rnd * 89999) 10000生成 1000099999 的五位随机数。同一个秒内最多产生约 9 万个不同文件名对于现场采集足够。另外在保存前加一层文件存在性检查fso.FileExists(savePath)若存在则再补一个_dup_后缀绝不覆盖。5.4 ASP 执行超时与假失败现象一张 5MB 的照片上传前端等了 40 秒后报失败但后端文件已经写完、数据库也插入了。前端重试一次产生重复记录。原因ASP 脚本默认Server.ScriptTimeout是 90 秒但如果处理函数里有大文件二进制转换、磁盘写入慢或者当时 IIS 繁忙脚本可能在写完文件但还没返回 JSON 响应时被强制终止。前端拿不到响应认为失败。解决一是页头显式把超时调长% Server.ScriptTimeout 300 %二是在文件写完、响应未返回之前把状态先写进一个内存标记表。更稳妥的办法是前端重试前先调一个query.asp?pathxx检查文件是否已存在存在就不重发只补写数据库记录。这个“后悔药”机制在线下弱网场景帮了我很多次重传风暴被直接掐断。5.5 弱网下的重试风暴手机 4G 断点后连续重试现象信号不好的写字楼地库用户连拍五张每张都失败重试重试又失败整个上传队列被卡死用户开骂。原因前面队列里我设置了 maxRetry2如果现场一直弱网第一张连续失败两次后直接 onFail队列会继续处理第二张但用户看到的全是失败列表。而且失败后手动点击重试会导致同一张照片在前面队列里被多次排队。解决把重试策略改成退避重试而不是立即重试。第一次失败等 3 秒第二次失败等 10 秒第三次失败把照片标记为“待上传”并允许用户手动单独重传该张。代码里用一个 setTimeout 包住 unshift 操作。catch (err) { if (item.retry this.maxRetry) { item.retry 1; const delay item.retry 1 ? 3000 : 10000; setTimeout(() { this.list.unshift(item); this.busy false; this.pump(); }, delay); } else { item.onFail(err); this.busy false; this.pump(); } }这个改动让现场用户感受到的是“上传慢”而不是“上传挂了”。慢可以接受挂了就没人愿意用了。5.6 连续上传时 Session 并发异常现象连续上传过程中用户发现部分图片入库了但登录状态掉了被迫重新登录后续图片传到了匿名目录。原因ASP 默认 Session 是进程内保存并发请求多了之后 Session 锁冲突或者 IIS 进程回收导致 Session 丢失。经典 ASP 的 Session 并发写支持很差手机上 WebView 并行上传会碰上。解决上传接口改为不依赖 Session改用一个短期的 upload token在页面打开时通过token.asp换取上传时把 token 放进自定义 header 或表单字段。这样即便 Session 回收只要 token 没过期上传流程不受影响。 token.asp 生成令牌 Dim token token GenerateToken(deviceNo, Now()) Session(UploadToken) token Response.Write token Function GenerateToken(deviceNo, nowTime) Dim base base deviceNo _ Hour(nowTime) Minute(nowTime) Second(nowTime) _ Int(Rnd * 9999) GenerateToken base End Function前端每次上传把 token 放进 FormData服务端在上传入口只核对 token 是否和 Session 里的值一致不一致就拒绝。注意这个方案只防接口被乱调不防高并发爆破因为 token 还在 Session 里Session 本身是瓶颈但已经足够覆盖现场身份校验的场景。6. 从“能传”到“传得稳”文件名、校验与压缩三板斧三斧子下去连续上传系统才算敢放开给人用。第一斧统一走服务端生成的唯一文件名绝不信任前端传的文件名。前端的 File.name 在不同品牌手机上五花八门有的叫 IMG_20250617_123456.jpg有的直接叫 1.jpg甚至重名。我在上一章里给出的 GenerateFileName建议把它抽成一个公共函数放到inc_save.asp所有上传入口共用。命名规则里带上日期目录/uploads/2025/06/17/xxx.jpg这样磁盘文件按天归档后面做冷备和清理都方便。第二斧服务端要校验文件是不是真图片。只看扩展名没用把 jpg 改成 png 的脚本文件也是图片后缀。实际的校验在 ASP 里读文件头几个字节JPEG 的开头是 FF D8 FFPNG 是 89 50 4E 47。Function IsValidImage(fileData) Dim header header MidB(fileData, 1, 4) If AscB(MidB(header,1,1)) HFF And AscB(MidB(header,2,1)) HD8 _ And AscB(MidB(header,3,1)) HFF Then IsValidImage True JPEG ElseIf AscB(MidB(header,1,1)) H89 And AscB(MidB(header,2,1)) H50 _ And AscB(MidB(header,3,1)) H4E And AscB(MidB(header,4,1)) H47 Then IsValidImage True PNG Else IsValidImage False End If End Function参数说明JPEG 只要校验前三个字节PNG 要校验前四个字节。文件头检查通过后再校验 file_size单张控制在 10MB超了就返回错误码让前端提示用户压缩。这个是防御不仅来自正常图片也来自无效的垃圾数据。第三斧图片压缩。手机原图随手一拍就是 48MB连续拍 50 张就是 300MB服务器磁盘吃紧、上传时间翻倍。常见做法是服务端用 ASP.NET 的 System.Drawing 缩成最长边 2000px 的 JPEG质量 80。经典 ASP 里没有内置图像库要么用第三方组件要么在手机上处理。我的做法是优先前端压缩canvas 把图片最长边缩到 2000pxtoDataURL(image/jpeg, 0.8)输出 Blob 再上传。这样服务端磁盘写的是压缩后的 200500KB 文件IIS 也不需要把请求体上限调到很大。function compressImage(file, maxSize, quality) { return new Promise((resolve, reject) { const img new Image(); const url URL.createObjectURL(file); img.onload function() { const scale Math.min(1, maxSize / Math.max(img.width, img.height)); const canvas document.createElement(canvas); canvas.width Math.round(img.width * scale); canvas.height Math.round(img.height * scale); const ctx canvas.getContext(2d); ctx.drawImage(img, 0, 0, canvas.width, canvas.height); canvas.toBlob(function(blob) { URL.revokeObjectURL(url); resolve(blob); }, image/jpeg, quality); }; img.onerror reject; img.src url; }); }maxSize填 2000quality填 0.8。这个参数组合在手机上基本看不出画质损失但体积能压掉 80% 以上。如果你对清晰度敏感比如定损拍照要看裂纹细节maxSize 提到 3000但要注意单张体积可能涨到 1MB 以上IIS 和带宽都得更宽裕。这三板斧做完这套“手机拍照无确认连续上传系统”基本可以从开发机搬到生产了。我自己做这套东西的习惯是上线头两周每天看一眼 upload_log 表里是否有空 file_path 记录、磁盘是否无故多出孤儿文件。如果发现孤儿文件说明前端 finish 批次接口和后端落盘之间还有断点抓紧在对应环节加补偿。这一路调试下来最大的教训就是“无确认”三个字骗不了人现场用户只会管你传上去没有、快不快——你前端优化做得再好服务端落盘不稳一切等于零。希望帮到你。本文还有配套的精品资源点击获取