先说个事儿
去年秋天帮一个开手冲咖啡店的朋友拍产品图，四十多张，豆子、杯子、手冲壶那一套。我用 Lightroom 调完直接批量导了 JPG，质量给到 92，微信原图发过去。她回了一句：怎么跟你在电脑上给我看的不一样，灰蒙蒙的。
我当时第一反应是她手机屏幕色温问题，让她关掉「原彩显示」再看，还是不一样。折腾到晚上十一点多我才反应过来——我导出时色彩空间选的是「ProPhoto RGB」，因为调色的时候一直在这个空间里。她手机、微信、公众号后台，没有一个是读 ICC 配置文件的。后来改成 sRGB 重导了一遍，她说「对了」。
这事之后我把自己的导出流程整个翻了一遍，也顺手测了不少工具。下面这些东西网上讲得都比较碎，我按我自己踩坑的顺序捋一遍。
掉进质量滑块里的那两年
先说一个可能有点反直觉的结论：一张照片从 4MB 压到 400KB，九成以上的体积是分辨率贡献的，质量滑块贡献的不到一成。
我拿 iPhone 12 拍的一张照片实测过。原图 4032×3024，12.2MP，Lightroom 导出质量 95，4.2MB。缩到长边 1600（也就是 1600×1200，1.92MP）之后，像素数只剩原来的 15.7%。这时候再给质量 82 导出，文件是 410KB 左右。等于体积降到原图的十分之一，其中绝大部分是砍像素砍下来的。
很多人（包括以前的我）会一直拖着那个质量滑块，从 100 拖到 60，文件可能只小了 30%，但画面已经开始糊了。在 Squoosh 里拿同一张图左右对比，质量 60 的天空渐变会出明显的色带，质量 90 基本看不出来。这个差距和「分辨率砍一半」的收益完全不成正比。
所以顺序应该是先定尺寸再定质量，反过来做基本是白费劲。网页用的图我一般长边 1600 到 2000，公众号封面 900×383，头像 400×400，这几个尺寸定死了之后质量随便给 80 出头就够了。
90 和 100 之间是一道断崖，不是斜坡
JPG 的质量参数有个很不直观的地方：它不是线性的。
Photoshop 里质量 90 以上，默认走 4:4:4 色度抽样，也就是色度信息一点不砍；掉到 90 以下，自动切 4:2:0，色度信息在横竖两个方向各砍一半。人眼对亮度敏感、对色度不敏感，这个设计本身没问题，但代价是：饱和的红色、蓝色的天空边缘、彩色的文字，会最先出问题。
我测过一张大红字体的海报，质量给 88 导出，放大到 200% 看，字的边缘有一层很淡的红边和锯齿。同样的图给 95，干干净净。所以 100 和 90 的差距其实不大（文件大小差 2 到 4 倍，画质差不太多），90 和 85 之间的差距反而更值得警惕。
我的判断标准比较粗暴：带文字、带 UI 元素、带大面积纯色块的图，不用 JPG，直接 PNG 或者 WebP 无损；纯照片类的，质量 80 到 85，色度抽样让它砍去，肉眼真看不出来。
顺便提一个我觉得被高估的事：WebP 和 AVIF 的收益没那么多人在吹的那么大。同一张照片，WebP 质量 78 大概比 JPG 质量 82 小 25% 到 35%，AVIF 质量 60 再小 20% 到 30%。但如果你已经把尺寸压到 1600 了，省下来的可能就是 400KB 变 280KB。真正让网页变快的是别放 4000px 的大图，不是格式。当然该转还是要转，白省的电不用白不用。
变色这件事，跟压缩一毛钱关系都没有
回到开头那个坑。颜色变了，问题几乎永远出在色彩空间上，跟质量参数无关。
sRGB IEC61966-2.1 是那个老掉牙但全世界都认的标准。Display P3 是苹果从 iPhone 7 开始默认用来拍照片的空间，色域比 sRGB 大一圈，尤其是红色和绿色往外扩得很多。问题就出在这：一张 P3 的图，如果 ICC 配置文件被剥掉了，接收方又默认按 sRGB 来解释这堆数值，颜色就会偏艳、过饱和；反过来，sRGB 的图被塞进 P3 环境里显示，就会发灰发淡。你说的「灰蒙蒙」和「怎么这么艳」，是同一个病的两种症状。
哪些操作会剥掉 ICC？Photoshop 的「存储为 Web 所用格式」会，macOS 预览的导出会，大部分在线压缩网站也会（它们顺手把 EXIF 一起清了）。
我现在的做法是：导出前统一「转换为配置文件」到 sRGB IEC61966-2.1，在 Photoshop 里是「编辑 → 转换为配置文件」，Lightroom 在导出面板的色彩空间那一栏选 sRGB。命令行的话，ImageMagick 加 -colorspace sRGB，或者干脆挂上 sRGB 的 ICC 文件。转完之后再压缩，顺序反过来就会出事。
我现在实际在跑的几条命令
图形界面我用，但批量处理还是命令行快。Mac 和 Linux 直接来，Windows 装个 WSL 或者 ImageMagick 的 Windows 版也一样。
HEIC 转 JPG，前提是你的 ImageMagick 编译时带了 libheif：
magick mogrify -format jpg -quality 92 *.heic
批量缩尺寸 + 导出，注意那个反斜杠，> 不转义的话 shell 会把它当重定向，然后你得到一个空文件并困惑半小时：
magick mogrify -resize 1600x1600\> -quality 82 -interlace Plane -strip *.jpg
-interlace Plane 是生成渐进式 JPG，网上加载的时候先出模糊轮廓再变清晰，体感快一点。-strip 会把 EXIF 全清掉——如果你的照片带 GPS 定位，发到公开场合之前建议加上；但如果是自己的存档，别加，拍摄参数是有用的。
PNG 压缩我用 pngquant，这个是有损的量化压缩，把颜色数从 1600 万降到 256 色以内：
pngquant --quality=65-80 --speed 1 --strip --ext .png --force *.png
--speed 1 是最慢最狠的档，一张 2000px 的 PNG 大概要三四秒。截图类的图能压掉 60% 到 70%，照片类的 PNG 压完会有明显的色带，别用。
转 WebP：
cwebp -q 78 -m 6 -metadata none in.jpg -o out.webp
-m 6 是最慢的压缩方法，一张图一秒多，换来大概 5% 到 10% 的体积。JPG 想再挤一挤可以用 jpegoptim：jpegoptim --strip-all --all-progressive -m82 *.jpg，无损优化大概能再省 3% 到 8%，聊胜于无。
AVIF 我偶尔用，avifenc -q 60 -s 6，比 WebP 再小两三成，但一张 12MP 的图要编十几秒，只有做静态资源的时候才值得，日常处理照片我放弃。
几个我自己踩过的坑
TinyPNG 免费版一次 20 张、单张上限 5MB（印象里是这个数，可能会变）。它压得确实不错，但带 GPS 的照片传上去，等于把拍摄地点交给了一个第三方，这个自己掂量。
macOS 预览导出 JPG，那个质量滑块默认只露三档，其实按住 Option 点它会变成连续滑块。而且它导出的图 ICC 是会被处理掉的，别拿它做最终交付。
微信发原图也会二次压缩。我测过一张 410KB 的图，发过去对方存下来看是 190KB 左右，文字边缘的锯齿能肉眼看出来。要保真的图我现在一律用网盘发，微信只发预览。
还有那些「AI 一键变清晰」的工具，本质是让模型猜像素。人像、天空、树叶这种纹理杂乱的场景效果确实不错，但产品图、文字截图、有明确 logo 的图，它会给你生成出根本不存在的东西，放大看全是瞎编的细节。商业交付千万别用。
最后
不是所有图都值得压。给客户的最终交付我反而用质量 92、保留 sRGB 和 EXIF，文件大点就大点，你无法预知对方用什么软件打开。
压缩是给网页和加载速度用的，不是给硬盘省地方用的。这两个场景的目标完全不一样，混在一起想，就会像我一样，在一个灰蒙蒙的晚上十一点，对着微信对话框发呆。