客户端图片压缩上传可显著节省流量，通过FileReader+canvas压缩JPEG、限制文件大小与数量、分块上传、禁用冗余字段及禁用重复提交按钮等措施实现。
客户端图片压缩再上传
原图直接上传是流量浪费的主因，尤其手机拍的 JPEG 常达 2–5MB。html5 的 FileReader + canvas 可在上传前压缩，不依赖后端。
- 用
URL.createObjectURL(file)快速预览，避免读取完整文件内容 - 将图片 draw 到
canvas后调用canvas.toBlob(callback, 'image/jpeg', 0.7)控制质量（0.6–0.8 是画质/体积平衡点） - 注意：ios safari 对
toBlob支持差，需 fallback 到toDataURL+dataUrlToBlob转换 - 压缩前检查
file.type，跳过非图像类型（如 PDF、MP4），避免无效处理
限制单次上传文件总大小与数量
前端不做限制，后端拦截只是补救；用户已传完才发现失败，白白消耗上行带宽。
- 用
input[type="file"].files遍历检查每个file.size，超过阈值（如 2MB）直接preventDefault()并提示 - 对多选上传，累加总大小并限制上限（如 10MB），而非只限单个文件
- 注意：
file.size是字节数，不是字符串长度；别误用file.name.Length - 移动端常触发多次选择（如微信内），建议绑定
change后立即清空input.value防重复提交
使用 FormData 分块上传 + 断点续传（大文件场景）
单次上传百 MB 文件失败重传全量，等于反复刷掉几十 MB 流量。分块本质是把一个大请求拆成多个小请求，失败只重传某一块。
- 用
file.slice(start, end)切片，每块控制在 1–5MB（太小增加 http 开销，太大降低并发容错） - 每次上传携带唯一
uploadId和chunkIndex，后端按序合并 - 前端记录已成功上传的
chunkIndex数组，页面刷新后可通过localStorage恢复续传状态 - 注意：Safari 对
slice()返回的Blob类型识别不稳定，建议统一转为new Blob([blob], {type: file.type})
禁用自动预加载与冗余字段提交
表单里看似无关的配置，可能悄悄拖走额外流量。比如带 preview 的上传组件，常默认加载缩略图或元数据。
立即学习“前端免费学习笔记（深入）”；
- 移除未使用的
accept="image/*"外的通配（如accept="*"），避免浏览器尝试解析所有文件类型 - 禁用
input的webkitdirectory或multiple若业务不需要——它们会触发批量文件扫描，部分浏览器会预读头部信息 - FormData 中只 append 真正需要的字段，避免
append('metadata', jsON.stringify(obj))传冗余描述（可用后端生成） - 上传前检查是否已有相同
file.lastModified+file.size的待传项，去重避免重复提交
const compressImage = (file, quality = 0.7) => { return new Promise((resolve, reject) => { const img = new Image(); img.onload = () => { const canvas = document.createElement('canvas'); const ctx = canvas.getContext('2d'); const maxSide = Math.min(1920, Math.max(img.width, img.height)); canvas.width = (img.width / maxSide) * maxSide; canvas.height = (img.height / maxSide) * maxSide; ctx.drawImage(img, 0, 0, canvas.width, canvas.height); canvas.toBlob(resolve, 'image/jpeg', quality); }; img.onerror = reject; img.src = URL.createObjectURL(file); }); };实际中最容易被忽略的是：用户点击上传按钮后，ui 未及时禁用按钮，导致连续触发多次上传请求——这比压缩算法失效更频繁地造成双倍流量。加 button.disabled = true 和恰当的 loading 状态，是最简单却最有效的“省流”操作。