前端图片压缩必须分三步走：上传时用Canvas实时压缩（优先naturalWidth/Height+toBlob）、交付时用<picture>和srcset双控格式与尺寸、部署时用CLI工具服务端兜底压缩，缺一不可。
直接上结论：前端图片管理压缩不能靠“一键工具”或“自动打包”，必须分三步走——上传时前端压缩、交付时格式+尺寸双控、部署时服务端压缩兜底。漏掉任意一环，都可能让压缩失效或引发兼容问题。
用户上传图片时，用 Canvas 做实时压缩
这是最常被跳过的环节：后端收到原图再压，既浪费带宽又拖慢上传速度。Canvas 是唯一能在用户点击“上传”前就完成降分辨率+转 JPEG 的方案。
- 必须用
img.naturalWidth/img.naturalHeight获取真实尺寸，img.width可能已被 CSS 修改，导致缩放变形 - 长边限制优先（如
MAX_WIDTH = 1200），再按比例算出短边，避免竖图被压扁 - 导出用
canvas.toBlob(callback, 'image/jpeg', 0.8)，别用toDataURL再转 Blob——iOS Safari 对toBlob支持不稳定，但toDataURL生成的 base64 字符串体积大、解析慢 - 原图是 PNG 且含透明通道？强制转 JPEG 会填黑底，体积反而更大；此时应保留 PNG，但只靠缩尺寸减体积，质量参数无效
HTML 中交付图片，必须同时控制 format + srcset
光压缩没用，浏览器仍可能加载错尺寸或不支持格式。交付阶段要靠 HTML 标签组合拳。
- 优先用
<picture>包裹多个<source>，明确指定type="image/webp"和type="image/avif"，最后 fallback 到<img src="fallback.jpg"> -
srcset必须提供至少两个宽度描述符（如"small.jpg 400w, medium.jpg 800w"），配合sizes属性（如"(max-width: 768px) 100vw, 50vw"）才能触发浏览器智能选择 - 服务器必须返回正确 MIME 类型：
image/webp和image/avif不能配错，否则 Chrome/Firefox 会静默忽略<source> - 别在 CSS 里用
width: 300px; height: auto缩放一张 3000×2000 的图——它仍会完整下载，浪费带宽
构建和部署阶段，用 CLI 工具批量处理静态图
开发时手动压缩不可持续，但盲目塞进 webpack 插件也容易翻车。关键是要分类型、有策略地跑 CLI。
立即学习“前端免费学习笔记（深入）”；
- WebP 转换用
cwebp -q 80 input.png -o output.webp，-q值 75–85 是画质/体积平衡点；AVIF 用avifenc --quality 80，但注意 Safari 16.4+ 才稳定支持 - PNG/JPEG 无损压缩用
oxipng -o 4 image.png或jpegoptim --max=85 image.jpg，它们只删元数据和优化编码，不改像素 - SVG 必须过
svgo --multipass，默认配置会删掉<title>和<desc>，如需无障碍支持，加--config='{ "plugins": [{ "name": "removeTitle", "active": false }]} ' - 字体文件用
font-spider提取实际用到的字形，别直接丢整包 WOFF2——中文字体动辄 2MB，子集化后常压到 200KB 内
最容易被忽略的是 EXIF 方向信息：iOS 拍照图自带 Orientation 标签，Canvas 绘制时不会自动旋转，结果上传后图是横的。必须用 exif-js 解析并在绘制前手动 rotate canvas，否则所有“压缩”都白做。
