先交代一下我为什么会写这个
上礼拜三晚上十一点多，一个做淘宝的朋友甩给我一张详情页截图，说「你看这图怎么这么糊，我原图明明很清楚」。我把他原图要过来——iPhone 14 Pro 拍的 HEIC，4032×3024，3.8MB，确实挺大。然后他干了三件事：PS 里导成 JPG 质量 60、长边缩到 750、最后又叠了 40% 的锐化。三刀下去，不糊才怪。
但有意思的是，他同一批图里另一张走了一模一样的流程，看着居然还行。差别在哪？糊的那张上面有个红色价格标签和一堆细小的中文字。我当时没多想，随口说了句「下次少加点锐化」，后来自己越想越不对劲，就把这事儿拆开重看了一遍。结论有点反直觉：大部分「图糊了」的问题，根源不在压缩率高低，而在你压缩的顺序，以及图里有没有那种天生就怕压的东西。
下面这些是我自己踩过坑之后攒下来的，不是教科书，你看着用，有对不上的地方以你自己的眼睛为准。
一、尺寸和质量，大部分人把优先级搞反了
打开任何导出面板，第一眼看过去的都是那个质量滑块，于是大家默认「质量」是主开关。其实不是。质量滑块决定的是「在这个尺寸下丢掉多少信息」，而尺寸决定的是「还剩多少信息可供丢」。一张 4032 宽的图缩到 750 宽，像素总量只剩原来的 3.5%，这个损失是质量滑块从 60 拉到 100 也补不回来的。
所以正确顺序应该是：先定最终展示尺寸（问清楚平台，别猜），再在这个尺寸上挑质量。淘宝详情页宽度长期是 750px，主图建议 800×800 起；小红书竖图我一般出 1080×1440；微信公众号正文图片宽度给到 1080 就够。你先按这些数把尺寸定死，再回头看质量，会发现 80 和 90 的差别没你想的大，但 750 和 1500 的差别是肉眼级的。
顺便说个冷知识：libjpeg 的默认质量就是 75，Photoshop「存储为 Web 所用格式」默认停在 60。这俩数字是二十多年前定下来的，跟你的图没关系，纯粹是历史遗留。别把它当金标准。
二、色度子采样：红色标签糊成灰边的元凶
回到我朋友那张图。JPEG 默认用 4:2:0 色度子采样——亮度信息保留全分辨率，色度信息的水平和垂直方向各砍一半，也就是彩色信息只剩四分之一。人眼对亮度敏感、对色彩不敏感，这个设计本身很聪明，日常照片看不出问题。
但它有个死穴：高饱和度的细小彩色元素。红色价格标签、彩色小字、带颜色的 1px 描边，全中招。因为色度被降采样之后再和亮度合并，红块的边缘会渗出灰边，远看就是「糊」。这不是分辨率不够，是色彩信息被扔了。
解决办法很简单，导出时把采样因子改成 4:4:4，体积大概涨 15%~25%，换来的是彩色边缘干净。我现在的做法是：图里有大面积纯色文字或彩色标签，一律 4:4:4；纯风景人像，4:2:0 省点体积没毛病。
（写到这儿发现我前面脑子里想的是「质量 85 是安全线」，其实对红色块不成立，见上面这段。）
三、格式怎么选，我自己的对照表
网上那些「WebP 比 JPEG 小 30%」的说法你肯定见过，数字大体没错，但场景不对就没意义。下面这张表是我自己用几十张实拍图和截图跑出来的粗略感受，不是实验室数据，别拿去当论文引用。
| 格式 | 有损/无损 | 体积（相对 JPEG） | 透明通道 | 我什么时候用 |
|---|---|---|---|---|
| JPEG | 有损 | 1.0 | 无 | 照片类最终交付，兼容性最稳 |
| WebP 有损 | 有损 | 约 0.6~0.75 | 有 | 网页首图、要兼容老安卓 |
| AVIF | 有损 | 约 0.45~0.6 | 有 | 新项目，不在乎编码时间 |
| PNG | 无损 | 3~10 倍 | 有 | 截图、线稿、UI 切图、还要反复改的中间稿 |
| HEIC | 有损 | 约 0.5 | 有 | 只在苹果生态里流转 |
两个坑得说清楚。AVIF 编码是真的慢，我拿一台 M1 的机器跑 100 张 4000 宽的图，WebP 大概两分半，AVIF 要十二分钟往上，浏览器端支持也是这几年才跟上。另一个坑是透明通道：PNG 转 JPG 背景会变黑或变白，看软件心情，这个我坑过不止一次。要透明就别转 JPG，直接上 WebP 或留着 PNG。
四、缩放算法和 gamma，这段有点枯燥但重要
缩小图片不是简单地「几个像素平均一下」。Lanczos 比 bicubic 更锐，代价是遇到高对比边缘会有轻微振铃（就是边缘出现一圈淡淡的重影）。我一般整图缩用 Lanczos，缩略图那种小尺寸用 Mitchell 或者直接 bicubic，振铃在小图上更显眼。
更隐蔽的是 gamma。大多数工具默认在 sRGB 空间里做缩放，但物理上的光强是线性的，这两者差一个 2.2 次方。结果就是缩完之后画面整体偏亮或偏暗，暗部细节拧成一团。ImageMagick 里可以用一行命令绕开：
magick input.jpg \
-colorspace RGB \
-filter Lanczos -resize 1600x \
-colorspace sRGB \
-sampling-factor 4:4:4 \
-quality 86 \
output.jpg提醒一句：ImageMagick 6 和 7 在 -colorspace RGB 这个命名上有过反复，两代含义不完全一样，你要批量跑之前先拿三张图对比一下再上量。我上次就是一晚上跑完 300 张，第二天打开发现整体灰了一层，只能重来。
五、锐化是补偿，不是补救
缩放一定会让图变软，所以缩完之后补一点锐化是合理的。但锐化不能救一张已经糊掉的图，它只会把糊的边缘描得更明显，看起来更脏。
我的参数一般是这个量级：
-unsharp 0x0.75+0.7+0.02也就是 sigma 0.75、强度 70%、阈值 0.02。阈值别设成 0，否则噪点会被一起放大。如果你是缩到很小（比如 400px 宽以下），强度降到 40%~50%，半径压到 0.5 左右。
我朋友那个 40% 锐化的问题不在数值，在于他是先锐化再缩小。这个顺序等于你精心描了一遍边，然后把它揉碎。顺序必须是先缩、后锐。
六、平台会再压一遍，你得提前留余量
这个最容易被忽略。你导出得再完美，传上去平台还会再压一次。微信朋友圈的图长边大概会压到 1280 上下，具体数字各家版本不太一样，我没法给你一个精确值，但方向是确定的：平台压得比你狠，而且用的是它们自己的参数，你控制不了。
所以我的做法是「反着来」：给平台的图，尺寸不要卡在它的临界值上，留一点余量，比如平台压到 1280，我就传 1600；质量不要顶到 95，因为高质量大文件平台反而压得更用力。听起来有点玄学，但你拿同一张图传 90 质量和 100 质量各一次，对比一下接收端看到的，大概能明白我在说什么。
还有个特别常见的翻车：用微信「发送原图」把文件传给同事。原图是原图，但微信在传输链路上是不是真的没动过，我到现在也没完全搞明白，反正我现在传工作图一律用网盘或者 AirDrop。
七、什么情况下不该压
前面说了这么多压缩技巧，得补一句反过来的话：有些图你就不该压。
截图、UI 切图、包含大量直线和纯色块的图，压完之后出现的块效应和色带比照片明显得多，这种直接上 PNG。需要存档的原片，留一份无损的别动。还有要反复修改的中间稿，每改一次存一次 JPG 就是一次有损叠加，改五轮下来画质掉得肉眼可见。我的习惯是中间稿一律 PNG 或者 PSD，最后交付那一刻才转 JPG。
最后说个我自己的局限：上面这些参数大部分是我在苹果设备和 Chrome 上测的，Windows 的显示器色彩管理和某些看图软件会再插一脚，你看到的效果可能和我描述的有出入。真要量产，最靠谱的还是拿你自己那批图，按这个顺序跑一遍，然后在最终的展示设备上看——不是在你的 4K 显示器上，是在用户那台手机上。
这话听着像废话，但我见过太多人在自己的专业屏上调到完美，发出去一片糊。