图片上传js压缩：在浏览器里把图片变小的思路与做法

先想清楚：压缩发生在哪一步

很多人的第一反应是“上传完再让后端压”，但真正影响体验的环节在提交之前。文件从 <input type="file"> 拿到手时还是原始字节，此时用 FileReader 或 URL.createObjectURL 读进内存，再交给 Image 对象解码，就能在画布上重绘。重绘时可以顺手把长边缩到一个合理范围，然后用 canvas.toBlob 输出新的图片数据，最后用 FormData 提交。

顺序弄反了会白忙一场：先上传再压缩，网络已经付出代价；先压缩再校验类型，可能把不该处理的格式也塞进画布。比较稳妥的顺序是校验扩展名与 MIME、读取尺寸、判断是否需要缩放、再决定编码参数。

画质和体积之间的那根线

压缩不是越狠越好。toBlob 的第二个参数是质量系数，对有损格式有效，调低会明显减小体积，但文字边缘和细密纹理容易发糊。经验上，照片类内容可以压得激进一些，截图、带文字的图、商品细节图则要保守。

另一个容易忽略的点是尺寸。把一张超大图缩到屏幕够用的宽度，往往比单纯降质量更划算，因为像素少了，编码后的数据自然小。缩放时保持宽高比，避免拉伸变形；如果原图本来就小于目标尺寸，就不要强行放大，放大只会增加体积而不增加信息。

还有透明背景的问题。转成有损格式会丢掉透明通道，图标、Logo 这类素材要么保留原格式，要么铺上合适的底色再输出。

一段能跑起来的处理思路

实际写的时候，可以把流程拆成几个小函数，方便单独调试。读取阶段用 createObjectURL 比 FileReader 更省事，记得在图片加载完成后调用 revokeObjectURL 释放引用，否则长时间停留的页面会积累内存。

绘制阶段创建画布，按计算好的目标宽高调用 drawImage。输出阶段用 toBlob 拿到 Blob，再包进 FormData 提交。如果项目里还有别的脚本要一起处理，压缩逻辑本身不必写得太花哨，保持可读即可；需要减小脚本体积时，可以借助 JS压缩 工具处理构建产物。

异步环节要留意错误分支：图片解码失败、画布被污染、toBlob 返回空值，都应该有兜底提示，而不是让上传按钮一直转圈。

哪些情况别硬压

前端压缩适合照片和普通插图，但并非万能。需要保留元信息的图片，比如带拍摄参数的原始素材，重新编码后这些信息通常就没了。动图经过画布重绘往往只剩第一帧，除非专门处理。超大尺寸的扫描件在低配手机上解码就可能卡顿，这时候更合理的做法是提示用户换图或交由服务端处理。

还要考虑兼容与降级：部分老环境对某些输出格式支持不完整，可以在 toBlob 回调里判断结果类型，失败时退回原始文件上传。压缩只是优化手段，不能成为上传失败的理由。

相关文章

• 代码压缩png：图片资源瘦身与代码处理技巧

  在开发者工具场景下，如何通过代码手段调整PNG图片资源，减少体积并融入构建流程。

• 代码压缩jpg质量不变：别再反复重编码

  解释 JPEG 重编码边界，给出系数域优化、元数据保留、校验与故障排查方法。

• url编码格式化：让链接参数不再难读

  解释url编码格式化的含义、常见场景与手动处理方法，帮助开发者读懂并整理冗长的链接参数。

• sql语句时间戳转换格式化：几个容易踩的坑

  聊聊 SQL 里时间戳转换与格式化的常见困惑：字段类型判断、时区偏移、函数差异，以及如何借助转换工具核对结果。

• sql将时间戳转换成指定格式化：怎么写才不踩坑

  讲清 sql将时间戳转换成指定格式化在各数据库中的差异，从格式串写法到时区陷阱，帮你在查询里得到想要的日期文本。

常见问题