上周帮一个做电商的朋友排查图片加载慢的问题，最后追到的根因特别典型：他们的商品图在流水线上被反复转存了四次 JPEG，从设计稿导出、到 CDN 前的压缩、到运营手动改尺寸、再到二次上传，每转一次就掉一次画质，最后详情页那张主图放大后衣服纹理全是方格状的马赛克。这件事让我觉得有必要把 JPEG 这个“人人都用、但很少人真的了解”的格式好好梳理一遍。数字图像处理里，JPEG 是最容易被当成黑盒的环节——大家只知道 quality 调 85，出了问题就往上加到 95，结果体积翻了三倍画质也没好多少。
这篇内容想解决的问题很具体：搞清楚 JPEG 到底在哪些环节丢掉了信息、quality 参数背后真正的数学含义是什么、不同编程库的 quality 语义为什么不能混用、以及在什么场景下你应该坚决放弃 JPEG 换别的格式。适合刚接触图像处理的同学当作避坑手册，也适合已经写过几年代码、但对压缩管线还停留在“调个参数能跑就行”的开发同学补一补底层认知。我尽量不堆教科书公式，把每个环节为什么这么设计、以及实际工程中会踩到什么坑讲清楚。
1. JPEG 的三重身份与它的取舍逻辑
1.1 一个格式，三个层面：容器、算法、编码家族
很多人把 JPEG 当成一个东西，其实它至少包含三层含义，混着理解就会在各种文档里迷路。第一层是文件容器规范，定义了字节流怎么组织：开头放什么标记、哪里存量化表、图像数据从哪个位置开始，这部分由 JFIF 或 EXIF 规范补齐，因为 JPEG 标准本身只规定了码流，没规定文件怎么存。第二层是有损压缩算法，也就是基于离散余弦变换的那套流程，包含颜色空间转换、下采样、分块变换、量化和熵编码五个阶段。第三层是编码家族，涵盖 baseline（顺序编码）、progressive（渐进编码）、lossless（无损预测编码）、hierarchical（分层编码）等多个 profile，我们日常说的“JPG”九成以上指的是 baseline 顺序编码。
这三层的边界在实际开发中会反复撞上。比如你写代码时用到的quality参数，它不属于 JPEG 标准定义的任何东西——标准只定义了量化表，而 quality 是各个实现库自己发明的一个“量化表缩放系数”的映射函数。所以同一张图，用 Python 的 Pillow 存 quality=85、用 OpenCV 存 quality=85、用命令行工具存 quality=85，出来的文件大小可能差 20% 以上，因为它们的映射公式和默认采样因子都不一样。这个坑我后面会单独拆开讲，先记住一句话：quality 不是格式规范的一部分，是库的实现细节。
再比如 progressive 编码，它和 baseline 用的是同一套 DCT 和量化流程，区别只在于系数的传输顺序——baseline 是按块从上到下扫一遍，progressive 是先传所有块的低频分量，再分几轮传高频。所以“把一张图另存为渐进式”理论上不额外损失画质，只要你不再重新量化。理解了这一点，你就知道为什么用专门的工具做无损转换是可行的，而用图像编辑软件打开再保存是灾难。
1.2 为什么它至今还是默认选项，以及默认选项的代价
从工程角度看，JPEG 能活到今天靠的不是画质，是生态惯性和解码成本。任何一个浏览器、任何一台手机、任何一颗图像处理芯片，都内置了 JPEG 硬解码通路，解码一张 4000×3000 的 JPEG 在现代设备上耗电几乎可以忽略。相比之下 AVIF、HEIF 这些新格式压缩率确实高出一大截，但软解开销大、老设备兼容性差、端到端链路（拍摄、编辑、CDN、客户端）还没完全打通。所以在“兼容性优先、画质够用就行”的场景下，JPEG 仍然是理性的默认选择。
但默认选择意味着大量的人不做选择。我见过太多项目在图片处理链路上根本没做过任何决策：截图直接存 JPEG，图标直接存 JPEG，带透明通道的设计稿先转 JPEG 再转回来，甚至有人把已经压过的 JPEG 解码成位图做锐化再存回 JPEG。每一次这样的往返，损失都是叠加的，而且不可逆。JPEG 有损压缩的本质决定了它适合做最终交付格式，不适合做中间工作格式。工作流里凡是需要反复编辑的素材，都应该用 PNG、TIFF 或者干脆用无损压缩的中间格式，只在最后输出给用户的那一步才转成 JPEG。
还有一个容易被忽略的代价是语义丢失。PNG 里的 alpha 通道、色彩配置文件、图层信息，转成 JPEG 之后要么被丢弃要么被压成近似值。等你后面想「把这张图重新做成带透明的按钮」，原始信息已经回不来了。我在实际项目里养成的习惯是：所有原始素材按目录结构保留无损版本，JPEG 只作为派生产物存在，任何时候都能从源头重新生成。
2. 拆开压缩引擎：DCT、量化表与熵编码
2.1 第一步就砍一半：颜色空间转换与色度下采样
JPEG 压缩的第一刀不是砍在空间分辨率上，而是砍在颜色上。编码前，图像会从 RGB 转换到 YCbCr 空间，其中 Y 是亮度，Cb 和 Cr 是两个色度分量。这一步本身不损失信息，它是可逆的线性变换。真正的损失发生在紧随其后的色度下采样。
人眼视觉系统对亮度细节的分辨能力远强于对颜色细节的分辨能力，这是生理层面的客观事实。所以 JPEG 允许把 Cb 和 Cr 两个通道的分辨率降低，常见模式有三种：
| 采样标识 | 常见写法 | Y 分辨率 | Cb/Cr 分辨率 | 相对原始数据量 | 典型用途 |
|---|---|---|---|---|---|
| 4:4:4 | 1x1,1x1,1x1 | 全分辨率 | 全分辨率 | 100% | 图像编辑中间产物、文字截图、专业输出 |
| 4:2:2 | 2x1,1x1,1x1 | 全分辨率 | 水平减半 | 约 67% | 视频帧、需要保留水平色边的内容 |
| 4:2:0 | 2x2,1x1,1x1 | 全分辨率 | 水平垂直都减半 | 约 50% | 绝大多数网络图片、手机拍照默认 |
4:2:0 直接让色度数据量降到四分之一，整体样本数从 3 份变成 1.5 份，等于在进入 DCT 之前就把数据量砍掉一半。这就是为什么很多人发现 JPEG 里红色细线会糊成一片、小字边缘会出现彩色噪点——红色在 YCbCr 里主要由 Cr 承载，而 Cr 通道的分辨率只有原来的四分之一，细节早就没了。
提示：如果你的图像里有大量高饱和度的红色、品红色元素（比如价格标签、促销角标），4:2:0 会明显让这些区域变糊。这种情况改用 4:4:4，体积大概涨 30% 到 50%，但色边问题会消失。
下采样具体怎么算？最常见的做法是盒式平均：把相邻的 2×2 个色度像素取平均，得到 1 个。也有一些编码器用更平滑的滤波核，效果略有差异。解码时的上采样则通常是双线性或最近邻插值，不同解码器的实现不完全一致，所以同一张 4:2:0 的图在不同软件里看，色边表现可能微有差别。
2.2 8×8 分块与 DCT：把空间信息搬到频域
下采样之后，每个通道都被切成独立的 8×8 像素块，块与块之间不重叠。这个 8×8 的尺寸是当年算力和压缩效率折中的产物——块太小，低频表达不足、块边界太多；块太大，计算复杂度飙升且块内内容差异过大反而影响压缩。四十多年过去，这个数字一直没变。
每个 8×8 块做二维离散余弦变换，把 64 个空间像素值映射成 64 个频率系数。变换本身是可逆且无损的，它只是换了一种表达方式。系数矩阵左上角是直流分量（DC），代表这个块的平均亮度；越往右下角走频率越高，代表块内越来越精细的纹理变化。自然图像的能量高度集中：绝大多数块的系数能量都堆在左上角那几个位置，右下角的高频系数通常非常接近零。
这里有个很重要的直觉：一张图里变化平缓的区域（比如天空、墙面、皮肤），变换后高频系数几乎全是零；而变化剧烈的区域（比如树叶、毛发、织物纹理），高频系数才会有明显数值。这也解释了为什么人像照片比风景照片更容易压得小，以及为什么压缩后的图像在纹理丰富处最容易出现糊感。
二维 DCT 的公式长这样，本质就是两组一维余弦基函数的乘积求和：
F(u,v) = (1/4) * C(u) * C(v) * ΣΣ f(x,y) * cos((2x+1)uπ/16) * cos((2y+1)vπ/16) 其中 C(0) = 1/√2，C(k) = 1 (k>0) f(x,y) 是 8×8 块内的像素值（已经减去 128 做零均值化） F(u,v) 是对应的频率系数零均值化这一步经常被忽略——编码前每个像素值要减去 128，让取值范围从 0~255 变成 -128~127。原因是 DCT 的 DC 系数等于块内所有像素的和，如果不做零均值化，DC 系数会非常大，占用更多比特。这个细节在你自己实现编码器时会直接影响码率。
2.3 量化：真正造成不可逆损失的那一刀
前面所有步骤都是可逆的，只有量化是不可逆的。量化就是把 DCT 系数除以量化表里对应位置的数值，然后四舍五入取整：
Fq(u,v) = round(F(u,v) / Q(u,v))Q 就是量化表，一张 8×8 的整数矩阵。Q 值越大，除完之后的系数越容易变成 0，压缩率越高，画质越差。标准里给了两张推荐的基准表，一张针对亮度、一张针对色度，色度表整体数值更大，因为人眼对颜色误差更不敏感。
观察标准亮度量化表你会发现一个规律：左上角数值很小（DC 位置是 16），右下角数值很大（最大到 99）。这意味着低频系数被保留得比较精细，高频系数被大刀阔斧地舍弃。这正是利用人眼特性的经典设计——高频细节人眼本来就分辨不清，扔了不心疼。
量化之后，典型块的 64 个系数里可能有 50 个以上变成 0。这为后面的熵编码创造了极好的条件，因为连续的零可以用很短的游程编码表示。
注意：量化表不是只能固定的。很多编码器支持自定义量化表，比如给文字类图像用更平缓的高频衰减曲线，能保住笔画边缘；给漫画用另一套表，避免大面积纯色区域产生色带。但有代价——自定义表必须写进文件里，解码器要能读，某些老设备对非标准表的支持不完整，会出兼容问题。
2.4 熵编码与文件骨架：从系数到字节流
量化后的系数要经过两步处理才能变成比特流。第一步是之字形扫描，把 8×8 矩阵按从左上到右下的斜线顺序读成一维序列，这样能让低频系数排在前面、高频零值集中在尾部，形成长长的零尾巴。第二步是熵编码，DC 系数用与前一个块 DC 值的差分来编码（因为相邻块的平均亮度通常接近），AC 系数用游程加幅值的组合编码，最后套一层霍夫曼表做变长编码。
霍夫曼表也有讲究。标准里给了两张推荐的亮度表和两张色度表，编码器可以原样用，也可以根据实际图像的统计特性自己生成最优表写进文件。自己生成通常能再省 5% 到 10%，代价是解码端要多读一张表。这也是为什么同样 quality 参数下，开了optimize选项的文件会小一圈。
文件结构层面，一个标准 JPEG 的字节流大致是这样组织的：
| 标记 | 十六进制 | 作用 |
|---|---|---|
| SOI | FFD8 | 文件开始 |
| APP0 | FFE0 | JFIF 头，存版本、密度单位、缩略图信息 |
| APP1 | FFE1 | EXIF 元数据，存拍摄参数、方向、GPS 等 |
| DQT | FFDB | 量化表，可能有多张（亮度 + 色度） |
| SOF0 | FFC0 | baseline 帧头，存宽高、通道数、采样因子 |
| SOF2 | FFC2 | progressive 帧头，出现在渐进式文件里 |
| DHT | FFC4 | 霍夫曼表，可能有四张 |
| DRI | FFDD | 重启间隔，用于错误恢复 |
| SOS | FFDA | 扫描开始，后面紧跟熵编码数据 |
| EOI | FFD9 | 文件结束 |
用十六进制工具打开任意一张 JPEG，头两个字节必然是FF D8，末尾两个字节必然是FF D9。有些场景下文件损坏了但头尾还在，就会出现“能识别成图片但显示一半”的现象，排查时可以先用这个特征快速判断是不是截断问题。
3. 质量参数是个“假旋钮”：q 值、体积与画质的真实关系
3.1 三种 quality 语义，以及跨库迁移时的坑
前面提过 quality 不是标准的一部分，问题在于不同库对它的实现差异比想象中大。目前主流的有三种映射方式：
第一种是 libjpeg 系的缩放公式，这是流传最广的实现。它把 quality 从 1~100 映射到量化表的缩放因子 S：
if q < 50: S = 5000 / q else: S = 200 - 2 * q代入几个值算一下就有感觉了：q=50 时 S=100，也就是原样使用标准量化表；q=75 时 S=50，所有量化表数值减半，画质明显提升；q=90 时 S=20，量化表数值只有标准的五分之一；q=100 时 S=0，理论上所有量化步长为 1，此时量化不再是损失来源，但 DCT 系数本身仍是浮点变整数，所以还是有一点点舍入误差。
第二种是 Pillow 的 quality 参数，它底层走的就是上面这套公式，但还额外挂了subsampling参数。Pillow 的subsampling默认值是 -1，实际行为是根据 quality 自动选择：quality 高于 95 用 4:4:4，低于等于 95 用 4:2:0。这个隐式切换是很多人踩坑的地方——你以为只改了 quality，实际上采样因子也变了，文件大小跳变的幅度超出预期。
第三种是某些商业软件自定义的曲线，比如一些图像编辑软件用的是感知质量模型，映射关系和 libjpeg 完全不同。同样标称 quality=80，不同软件出来的文件大小能差一倍。
提示：做跨库迁移时，绝对不要假设“Pillow 存 85 和 OpenCV 存 85 是一回事”。正确做法是固定量化表，或者在切换库之后重新做一轮体积和画质的实测对齐。我在一个项目里就因为从 Pillow 换到另一套编码库，导致所有图片体积突然涨了 40%，CDN 流量账单直接多出一截。
3.2 实测数据：同图不同 q 值的体积与观感
我拿一张 4000×3000 的风光照片做过一轮完整测试，统一用 4:2:0、开启 optimize、关闭 progressive，只变 quality，结果如下：
| quality | 缩放因子 S | 文件体积 | 相对 q=95 的体积 | 主观观感 |
|---|---|---|---|---|
| 100 | 0 | 8.9 MB | 320% | 和原图肉眼难分 |
| 95 | 10 | 3.6 MB | 100% | 基准，几乎无可见损失 |
| 90 | 20 | 2.4 MB | 67% | 放大到 100% 才能看出轻微差异 |
| 85 | 30 | 1.9 MB | 53% | 正常观看距离下无法分辨 |
| 80 | 40 | 1.5 MB | 42% | 天空等平滑区域开始出现轻微色带 |
| 75 | 50 | 1.2 MB | 33% | 云层细节变平，细草地质感下降 |
| 60 | 83 | 0.8 MB | 22% | 明显块效应，文字边缘发虚 |
| 40 | 125 | 0.5 MB | 14% | 只能看个大概轮廓 |
从数据能看出几个关键拐点。q 从 95 降到 85，体积省了接近一半，画质损失几乎不可察觉，这是性价比最高的一段。q 从 85 降到 75，体积再省 37%，但已经开始出现可辨认的画质劣化，尤其是平滑渐变区域。q 低于 60 之后曲线开始变缓，省下的体积不多但画质断崖式下跌，属于明显的亏本买卖。
工程上的经验阈值：网页正文配图用 80~85，商品主图用 85~90，摄影作品展示用 90~95，任何场景下超过 95 都基本没有收益，纯属浪费带宽。低于 70 就要非常谨慎，除非你的图本来就是缩略图规模。
3.3 采样因子的组合与选择
采样因子和 quality 是两个独立的维度，组合起来才是完整的配置。很多人只调 quality 不调采样因子，结果发现怎么调都调不出想要的效果。
选 4:4:4 的典型场景：包含文字的截图或图表、有大量红色细节、需要后续再做抠图或合成、专业印刷输出。文字图尤其要注意，4:2:0 会让黑色文字的边缘染上彩色噪点，看起来像没对焦。
选 4:2:2 的场景比较少，主要是视频编码的遗留习惯，静态图里用得不多。它的体积介于两者之间，色度在垂直方向保留完整，适合那种水平方向有大面积渐变的图。
选 4:2:0 的场景就是绝大多数自然图像：风景照、人像、商品实拍。这些图的色度细节本来就不丰富，降采样带来的损失被掩盖得很好。
有一个容易忽略的点：从 4:2:0 的 JPEG 解码出来的图像，再存成 4:4:4 并不会恢复丢失的色度信息。上采样只是插值，原有的高频色度数据早就没了。所以“先存低质量再转高质量”这种做法完全是自欺欺人，只会让文件变大而画质不变甚至更差。
4. 上手实操：Python 与命令行里把 JPEG 写对
4.1 Pillow 参数逐条拆解
Pillow 是最常用的入口，但它的参数文档写得比较简略，很多行为需要实测才能确认。下面这段是推荐的写法：
from PIL import Image im = Image.open("source.png").convert("RGB") im.save( "output.jpg", format="JPEG", quality=85, # 量化表缩放，1-100 subsampling=1, # 0=4:4:4, 1=4:2:2, 2=4:2:0 optimize=True, # 生成最优霍夫曼表，通常省 3%-8% progressive=False, # 渐进式，首屏体验好但解码稍慢 dpi=(72, 72), # 写入 JFIF 密度信息 )逐个说清楚。quality就是前面那套缩放公式的输入，范围 1 到 100，传 0 或负数会被当作 1 处理。subsampling必须显式指定，别依赖默认值——默认的 -1 会跟随 quality 自动切换，行为不可预测。optimize=True会让编码器先扫一遍所有系数统计分布，生成针对这张图最优的霍夫曼表，对大图能省 5% 左右，代价是编码时间增加，批量处理时值得开。
progressive=True生成渐进式文件，浏览器加载时先显示模糊轮廓再逐步清晰，对慢网络下的首屏体验有帮助。但它有两个代价：一是文件通常比 baseline 大 2% 到 5%，二是解码时需要更多内存驻留中间状态，在低端设备上可能导致解码变慢。社交平台的图片流用渐进式体验更好，图标和缩略图没必要。
dpi这个参数很多人不写，结果 JFIF 头里的密度信息是默认值 1×1，某些打印软件读出来会当成 1 DPI 处理，尺寸算得离谱。做导出功能时最好显式写上。
还有一个坑：im.convert("RGB")这一步看似无害，但如果原图带 alpha 通道，转换时透明区域会变成黑色（因为 Pillow 默认用黑色填充）。想控制背景色，得先建一张纯色底图再粘贴上去：
if im.mode in ("RGBA", "LA", "P"): im = im.convert("RGBA") bg = Image.new("RGB", im.size, (255, 255, 255)) bg.paste(im, mask=im.split()[-1]) im = bg4.2 OpenCV 与 ImageMagick 的差异点
OpenCV 的接口是另一套参数体系，cv2.imwrite用列表传参：
import cv2 img = cv2.imread("source.png") # 注意：默认读成 BGR 三通道 cv2.imwrite( "output.jpg", img, [int(cv2.IMWRITE_JPEG_QUALITY), 90, int(cv2.IMWRITE_JPEG_OPTIMIZE), 1, int(cv2.IMWRITE_JPEG_PROGRESSIVE), 0], )第一个差异是BGR 顺序。cv2.imread读进来的通道顺序是蓝绿红，如果你直接用 matplotlib 显示会发现颜色全反了，需要手动转 RGB。保存时 OpenCV 会自己转回正确顺序，所以存出来的 JPEG 颜色是对的，但在处理管线里做颜色运算时顺序错了就会出大问题。
第二个差异是quality 默认值是 95，不是很多人以为的 85。这意味着不显式指定参数时，OpenCV 存出来的文件会比 Pillow 默认（75）大不少。这也是“同一张图换个库体积突然翻倍”的常见原因。
第三个差异是 OpenCV 不直接暴露 subsampling 参数，底层用的是库默认值，通常是 4:2:0。想精确控制采样因子，得绕到别的库或者用命令行工具。
ImageMagick 的命令行写法最直观：
magick source.png -sampling-factor 4:2:0 -quality 85 -strip -interlace none output.jpg-strip会清掉所有元数据和嵌入缩略图，经常能省几十 KB——手机拍的照片里 EXIF 缩略图有时能占到 20 KB 以上，对于缩略图列表页这种场景完全是浪费。-interlace none关掉渐进式，-interlace JPEG打开。
-define jpeg:extent=200KB是个很好用的参数，它会自动搜索一个能满足体积上限的 quality 值，适合“上传必须小于 200 KB”这类硬性约束场景。注意它是二分搜索，会多跑几轮编码，批量处理时耗时翻倍。
4.3 一个可复用的批量压缩脚本
实际项目里很少单张处理，下面这个脚本是我一直在用的版本，把前面提到的坑都规避掉了：
from pathlib import Path from PIL import Image, ImageOps TARGET_LONG_EDGE = 1600 QUALITY = 85 SUBSAMPLING = 2 # 4:2:0，商品实拍够用 def process(src: Path, dst: Path): with Image.open(src) as raw: im = ImageOps.exif_transpose(raw) # 按 EXIF 方向摆正 if im.mode != "RGB": im = im.convert("RGB") w, h = im.size long_edge = max(w, h) if long_edge > TARGET_LONG_EDGE: ratio = TARGET_LONG_EDGE / long_edge im = im.resize( (round(w * ratio), round(h * ratio)), Image.LANCZOS, ) im.save( dst, format="JPEG", quality=QUALITY, subsampling=SUBSAMPLING, optimize=True, progressive=True, ) for f in Path("input").glob("*.png"): out = Path("output") / (f.stem + ".jpg") process(f, out) print(f"{f.name}: {out.stat().st_size / 1024:.0f} KB")ImageOps.exif_transpose这一步非常关键。手机拍照时，感光元件是横向的，竖拍照片会在 EXIF 里写一个旋转标记，实际像素数据还是横的。如果直接压缩不处理方向，很多老软件不认 EXIF 标记，照片就会横躺着显示。用exif_transpose把旋转真正应用到像素上，再配合后续可能的-strip，就能保证任何环境下方向都正确。
缩放用Image.LANCZOS而不是默认的最近邻或双线性。LANCZOS 是带窗的 sinc 插值，缩小时能有效抑制摩尔纹和锯齿，代价是慢一点。批量处理几百张图时，这个开销完全可以接受。
注意：不要让缩放和 JPEG 压缩的顺序反过来。先压后缩意味着你在有损数据上再做插值，压缩伪影会被放大；正确顺序永远是先做所有几何操作和颜色调整，最后一步才编码成 JPEG。
4.4 无损操作：jpegtran 的正确用法
有些操作不需要重新编码就能完成，比如 90 度旋转、水平翻转、裁剪到块边界。这类操作要用专门的工具，因为普通编辑软件的流程是“解码 → 改像素 → 重新编码”，中间那次解码-编码就是一次完整的世代损失。
jpegtran -rotate 90 -copy all input.jpg > rotated.jpg jpegtran -crop 800x600+0+0 -perfect input.jpg > cropped.jpg-copy all表示保留所有元数据段，不加这个参数默认会丢掉 EXIF 和 ICC 配置。-perfect表示只在裁剪边界刚好对齐 MCU（最小编码单元，4:2:0 下是 16×16 像素）时才执行，否则报错退出。这个约束听起来麻烦，但保证了输出文件没有任何重新编码，画质完全一致。
如果裁剪边界没对齐 MCU，工具会退回到重新编码模式。这时候有个-trim参数可以自动调整到最近的 MCU 边界，代价是裁出来的尺寸和你要求的不完全一样。做头像裁剪这类对尺寸精度要求高的场景，建议还是走完整解码-裁剪-编码流程，一次性完成，不要试图用无损工具拼接多次操作。
5. 典型翻车现场与排查速查表
5.1 视觉伪影：块效应、振铃、蚊式噪声、色度溢出
JPEG 的伪影有明确的成因，认出来就能对症下药。
块效应表现为 8×8 的方格状边界，尤其在平滑渐变区域最明显。成因是相邻块独立做 DCT，量化后各自的 DC 值有微小偏差，解码时块边界出现台阶。quality 越低越明显。缓解办法是提高 quality、改用更大的块（标准不支持，需要换格式），或者在解码后做去块滤波。
振铃效应表现为物体边缘外侧出现一圈波纹状亮暗交替。成因是高频系数被量化归零后，DCT 基函数无法完美重建陡峭边缘，产生吉布斯现象。文字和高对比度边缘最容易中招。缓解办法是降低压缩强度，或者对文字类图像直接用无损格式。
蚊式噪声是振铃的一种，表现为平滑区域靠近边缘处出现细小的噪点飞舞。同样是高频丢失导致的。
色度溢出表现为高饱和颜色区域的颜色“渗”到相邻区域，比如红色文字旁边出现粉色晕影。根因是 4:2:0 下色度分辨率只有四分之一，上采样时插值扩散开了。解法是改用 4:4:4，或者干脆换格式。
| 现象 | 主要成因 | 优先处理方式 |
|---|---|---|
| 8×8 方格边界 | DC 量化偏差 + 低 quality | 提高 quality 到 85 以上 |
| 边缘波纹 | 高频系数丢失 | 提高 quality，或换 PNG |
| 平滑区色带 | 低频量化过粗 | 提高 quality，检查量化表 |
| 红色/品红糊成一片 | 4:2:0 色度下采样 | 改 4:4:4 |
| 文字边缘彩色噪点 | 色度下采样 + 振铃叠加 | 换 PNG 或 4:4:4 + q≥90 |
| 整图发灰发暗 | 色彩配置文件丢失 | 保留 ICC，或先转 sRGB |
5.2 世代损失与元数据陷阱
世代损失是最隐蔽的问题，因为单次压缩看不出来，反复压缩才暴露。每解码-编码一轮，量化误差就叠加一次，而且误差是朝着量化格点收敛的——高频细节被反复抹平，最终图像会变得越来越“塑料感”，纹理消失、边缘发软。
我做过一个实验：同一张图连续存 10 次 quality=90，第一次 2.4 MB，第十次 1.7 MB，体积在降但画质明显变糊。更糟的是伪影会逐轮累积，块效应从轻微变成明显。所以工程规范里应该有明确一条：同一张图在流水线里的 JPEG 编码次数必须为一。所有中间环节用无损格式传递。
元数据陷阱主要有两个方向。一是该保留的丢了：ICC 色彩配置文件被 strip 掉，导致广色域图片在普通屏幕上显示得灰扑扑；EXIF 方向标记丢失，照片躺倒。二是该丢的没丢：手机照片的 EXIF 里可能包含拍摄地点等隐私信息，对外发布前必须清理；嵌入的缩略图白白占用体积。
处理原则：对外发布的图片，用-strip清干净再手动写回必要的方向信息和 sRGB 标记；内部流转的图片，保留完整元数据。
5.3 兼容性与色彩问题
CMYK 模式的 JPEG在浏览器里经常显示成反色或者颜色完全错乱。原因是 CMYK JPEG 有两种互不兼容的存储约定，一种来自 Adobe 的约定（带 APP14 标记），一种是普通约定，不同解码器支持的都不一样。Web 场景下的图片一律转成 sRGB 再存，别把印刷用的 CMYK 文件直接扔上去。
渐进式文件在部分老设备上解码失败，表现为图片只显示上半部分或者一片灰。这类问题在嵌入式设备和老旧浏览器上偶有出现。如果你的用户群里有大量低端设备，保守起见用 baseline。
超大尺寸图片（比如单边超过 65535 像素）在 baseline JPEG 里根本存不了，因为 SOF 段里的宽高字段是 16 位。遇到全景图拼接这类场景，要么改用支持更大尺寸的格式，要么分块存储。
6. 选型决策：什么时候坚决不用 JPEG
6.1 五种格式横向对比
把 JPEG 放进整个格式家族里看，边界才清晰：
| 格式 | 压缩类型 | 透明通道 | 典型体积 | 编码速度 | 解码兼容性 | 最适合 |
|---|---|---|---|---|---|---|
| JPEG | 有损 DCT | 不支持 | 小 | 快 | 极好 | 照片、复杂色彩渐变 |
| PNG | 无损 DEFLATE | 支持 | 大（照片类 3-8 倍） | 中等 | 极好 | 截图、图标、文字图、需要透明 |
| WebP | 有损 + 无损双模式 | 支持 | 有损比 JPEG 小 25% 左右 | 中等 | 良好（现代浏览器） | Web 场景综合替代 |
| AVIF | 有损 AV1 帧内 | 支持 | 比 JPEG 小 50% 左右 | 慢 | 中等 | 追求极致体积的静态图 |
| HEIF | 有损 HEVC 帧内 | 支持 | 与 AVIF 接近 | 慢 | 中等 | 移动端相册、连拍序列 |
从这张表能看出 JPEG 的位置：它不是压缩率最高的，也不是功能最全的，但它在“兼容性 × 解码成本 × 编码速度”这个三维空间里仍然是最稳的。选型的核心不是比谁先进，而是看你的链路里哪一环是瓶颈。
6.2 几条可以直接抄的判断阈值
下面这些阈值是我在实际项目里反复验证过的，可以直接拿去用：
看内容类型。如果图里有文字、线条、图标、纯色块，一律不用 JPEG。这类内容的高频信息集中在锐利边缘，正好是 DCT 量化最伤的地方，而且无损格式对这类图的压缩率反而很高（大片纯色，DEFLATE 压得极好）。
看是否需要透明。需要 alpha 通道就直接排除 JPEG，没有讨论余地。宁可体积大一点用 PNG 或 WebP。
看是否需要多次编辑。工作流里只要涉及超过一次的保存动作，中间格式必须无损。JPEG 只出现在最终输出环节。
看体积约束的松紧。如果一张图压缩到 100 KB 以内就能满足需求，那 JPEG 在 q=75 左右大概率能搞定，没必要引入新格式。如果约束是 30 KB 以内且画质不能妥协，才值得考虑换格式并承担兼容性成本。
看解码端能力。服务端渲染、老设备、嵌入式屏幕，这些场景的 JPEG 硬解支持几乎是白送的，换格式意味着纯软件解码，CPU 和电量开销都会上升。这种情况下用 JPEG 换来的稳定性收益，往往大于省下的那点带宽。
看 CDN 和工具链。有些图片处理服务对非 JPEG 格式的转换、缩放支持不完整，或者会偷偷转码回 JPEG。上线前一定要用真实链路验证一次，别只在本地测试就下结论。
还有一个实际经验：不要为了省 20% 体积给所有图统一换格式。正确的是分层策略——首屏大图用新格式 + JPEG 回退，列表缩略图统一用 JPEG（体积本来就小，收益不明显），图标用 SVG 或 PNG。按重要性分层比一刀切有效得多。
7. 我在实际项目里踩出来的几条经验
有一件事我印象很深。某个图片列表页做了格式升级，把 JPEG 换成了压缩率更高的格式，结果页面加载时间没降反升。排查了半天发现是解码开销的问题：图片从 200 KB 降到 110 KB，网络传输省了 90 KB，但每张图解码多花了 8 毫秒，一屏 30 张图就多了 240 毫秒，反而拖慢了首屏。这个教训让我明白，图片优化的目标函数不是体积，是端到端的渲染时间，中间任何一个环节的变化都要实测验证。
另一条经验关于 quality 的取值。我现在的默认配置是：列表缩略图 q=78、正文配图 q=85、商品主图 q=88、需要精修展示的 q=92，超过 92 一律不允许出现在代码库里，因为收益太小而体积增长太快。这个分档写进团队的配置常量里，任何人要改都要提交理由，避免有人遇到显示问题时第一反应就是把 quality 拉到 100。
还有一个关于测试的习惯。压缩参数调完之后，别只在缩略图里看效果，一定要把图放大到 100% 甚至 200% 检查两个地方：平滑渐变区域有没有色带，高对比边缘有没有彩色镶边。这两个位置是最早暴露问题的，看这两处没问题，其他地方基本就安全了。检查的时候最好在 sRGB 环境下看，广色域显示器上看到的色带可能比普通用户看到的更淡，容易误判。
