上个月替我妈在手机上传妹妹的报名时照片，页面要求"一寸照，JPG，500KB 以内"，她拍完直接选中相册里那张——3024×4032，6.1MB，红字提示刷了三次：文件大小超出限制。我先在手机上裁了又裁，还是不行，最后拿到电脑上才想通问题在哪：我一直在调"裁剪框"，可真正决定体积的是像素总数和编码质量，不是显示尺寸。那次之后我自己网站上所有配图也顺手过了一遍，首屏加载从 3.4 秒降到 1.9 秒。这篇就写这两件事的结论。
一、一张照片的体积由什么决定
把"图片太大"当成一个问题拆开来，其实是三层：
- 像素总数：4032×3024 是 1220 万像素，1600×1200 是 192 万，差了六倍多。这一层不动，后面压得再狠也有限。
- 编码与质量：同样的像素，JPG 质量 95 和质量 75 可能差三到五倍体积；同一画面存成 PNG 通常比 JPG 大得多，因为 PNG 的无损算法不擅长处理照片那种连续渐变。
- 附带数据：EXIF、拍摄时间、相机型号、GPS 坐标、内嵌缩略图，一张手机原图里这部分常有几十到上百 KB，而且是最容易泄东西的地方。
我自己量过的参照值：手机直出的 JPG 照片 2–4MB；一张 1440×900 的桌面截图存 PNG 约 1.1MB，同一张转成 JPG 质量 80 只剩 180KB 上下；标准一寸照 295×413 像素，JPG 质量 85 通常在 40–70KB。所以我妈那张 6.1MB 的照片要落到 500KB，本来就不是"稍微压一下"的量级。
二、先降尺寸，再调质量：顺序反了就白折腾
常见错误是先拿一张 4000 像素宽的图去压质量，压到 40% 才勉强过线，文字边缘已经糊成一团；而正确做法是先按用途把长边缩到需要的像素，再用中等质量收尾。我用的参考档位：
| 用途 | 建议长边 | 质量档 | 经验结果 |
|---|---|---|---|
| 报名/证件照上传（295×413 一类） | 按平台像素要求 | JPG 80–90 | 几十 KB，远低于 500KB 限制 |
| 博客配图、商品详情 | 1600–2000 | 75–85 | 150–350KB，肉眼看不出损失 |
| 首屏大图 | 1200–1600 | 70–80 | 再配懒加载，LCP 才压得住 |
| 聊天记录、文档截图 | 保持原始像素 | PNG 无损或 WebP | 宁可无损，文字边缘不能糊 |
| 发给客户的产品图 | 按对方要求 | 85–92 | 留原图，另存一份压缩版 |
那张 6.1MB 的照片，我最后是把长边收到 1200、质量给到 82，出来 240KB，打印一张一寸的排版还够用。整个过程里起作用的是尺寸那一步，不是质量滑块。
三、无损、有损，还有格式选择
无损是重新组织数据的存法，像素一个都不改；有损是允许丢掉一些人眼不敏感的信息。选择取决于图的内容，不是"哪个更高级"：
| 格式 | 透明 | 擅长 | 短板 |
|---|---|---|---|
| JPG | 不支持 | 照片、渐变、体积敏感的场景 | 文字边缘出现色带；反复另存会累积损失 |
| PNG | 支持 | 截图、图标、线条图、需要透明 | 照片类体积偏大 |
| WebP | 支持 | 网页配图，同等画质体积更小，还能装动画 | 极老环境打不开，需留 JPG 兜底 |
有损这一层还有个隐性代价：每次用有损格式重新保存并导出，都会再叠一次损失。所以我的习惯是原图永远留着，压缩只产出副本，需要调整参数时从原图重跑，而不是在压缩结果上再压一遍。
四、我实际的处理流程
- 先判断是尺寸问题还是编码问题：把图放大到 100% 看细节，如果本来就是 4000 像素宽而页面只显示 800 像素宽，那答案在尺寸。
- 尺寸过大的先用图片尺寸调整按像素或百分比缩，勾上锁定宽高比，避免拉变形；这一步支持 PNG、JPG、WebP、GIF、BMP。
- 再进图片压缩批量处理：一次拖十几张，质量在 10% 到 100% 之间调，页面上直接对比压缩前后的文件大小和压缩率，效果即时可见，我一般从 80 起往下试两档。
- 需要透明通道的 PNG 单独看一遍，确认 Alpha 还在；截图类优先无损档。
- 导出的副本按日期重命名放回去，原图不动。整套处理都在浏览器本地跑，图不上传服务器——这一点对客户素材和证件照很重要。
五、容易被忽略的细节
- GPS 跟着原图走：iPhone 直出的照片 EXIF 里常带经纬度，微信"发送原图"也会一并传出去。给人发证件照前，要么用截图法重制，要么在导出时去掉附带信息。
- 平台的二次压缩：微博、微信、部分电商后台会再压一遍你的图。已经压得很低的图被压两次，画质是叠加变差的，传上去反而更糊。
- 透明背景存 JPG 会变黑底或白底：JPG 不认 Alpha，压之前先确认目标格式，或者铺一层底色再导。
- HEIC 与 iOS 相册：iPhone 默认存 HEIC，很多网页表单只认 JPG/PNG，上传前要先转一次格式。
- 首屏性能账：我自己站点上图片占了首屏资源的六成左右，LCP 判定的"良好"线是 2.5 秒以内。首屏那张大图单独优化，收益通常比压缩下面二十张小图更大。
- GIF 是体积大户：帧数多的 GIF 靠压缩质量救不了，先减尺寸或减帧才是正解。
六、常见疑问
Q：平台限制 500KB，是该降质量还是缩尺寸？
先缩尺寸。像素减一半，体积大约降到四分之一，画质几乎无感；单靠压质量往往要压到四五十才能过线，边缘和皮肤会一起烂掉。
Q：压缩会让画质明显变差吗？
无损不动像素，不会有变化；有损在 75 到 85 这个区间，对照片类内容通常肉眼分不出。要判断就在 100% 缩放对比文字边缘和头发丝，那两处最先露馅。
Q：截图发群里该用什么格式？
PNG 或者 PNG 的无损压缩。截图里全是硬边文字和纯色块，有损压缩会在字缘生出色带，看着比原图脏。
Q：WebP 会不会有人打不开？
近几年的主流浏览器和系统都支持，网页里可以直接用。要发给不特定的外部人群，还是保留 JPG/PNG 更稳。
Q：批量的时候会不会把原图覆盖掉？
我的做法是原图单独放一个目录、只读，压缩结果输出成副本再改名。任何带"覆盖原文件"意思的操作都不该用在原片上。
回到开头那张 6.1MB 的照片。它最后没被压到极限，只是收到 1200 像素、质量 82、240KB 就通过了审核——限制是给人看的，不是给画质看的。真正需要记住的顺序只有两条：先看像素够不够用，再看格式和档位对不对；剩下的都是可重复调的旋钮。