处理一批图片时，我最怕听到一句“全部转成 JPG 就行”。这句话听起来像举手之劳，实际藏着一堆决策：质量给多少、色度要不要降采样、渐进式要不要开、元数据留不留、原图是截图还是照片。这几个参数随便点一个，出来的东西可能差出三成体积和肉眼可见的画质鸿沟。JPG/JPEG 是数字图像处理里最老资格、也最容易被当成“默认选项”的格式，恰恰因为它太常见，大部分人从来没认真看过它内部到底在干什么。这篇就把我自己这些年调 JPEG 参数、处理批量转码、排查“图片怎么糊了/怎么变大了/怎么打开是黑的”这些问题的经验摊开讲，从编码原理一路讲到可复制的代码，适合刚接触图像处理的同学，也适合已经写过几年代码但一直靠默认参数混日子的老手对照排查。
1. 先搞清楚 JPEG 不是“存像素”，而是一条有损加工流水线
很多人对 JPEG 的认知停留在“一种比 PNG 小的图片格式”，这个理解会让你在参数调优时完全失去方向感。JPEG 的本质不是像素容器，而是一套完整的编码流程：它拿到 RGB 像素之后，会先换颜色空间、再做分块变换、然后量化、最后熵编码，中途的每一步都在丢信息，只是丢得聪明。你设定的那个“质量 80”，实际影响的是流水线上某个特定环节的力度，而不是一个全局的“清晰度滑块”。
1.1 从 RGB 到 YCbCr：先把颜色拆成“明暗”和“色相”两路
JPEG 的第一步不是压缩，而是换坐标系。原始图像是 RGB 三个通道，每个通道都承载亮度信息，彼此高度相关，直接压缩效率很低。编码器会把它转换成 YCbCr：Y 是亮度，Cb 是蓝色色度偏差，Cr 是红色色度偏差。这个转换是线性可逆的，本身不丢信息，但它把“明暗细节”和“颜色细节”彻底分开了，后面的压缩才能区别对待。
为什么要这么折腾？因为人眼这个传感器的特性很偏科。视网膜里负责分辨细节的视锥细胞，绝大多数集中在处理亮度信息上，对颜色的空间分辨率要低得多。你可以做个简单的实验：找一张彩色照片，把它转成灰度，你会发现轮廓、纹理、层次全都还在；反过来只保留颜色丢掉亮度，画面立刻变成一团模糊色块。JPEG 就是吃准了这一点，把大部分比特预算砸在 Y 上，色度通道则可以大刀阔斧地砍。
换算公式在标准里有明确定义，实现时通常用整数近似：
Y = 0.299R + 0.587G + 0.114B Cb = -0.1687R - 0.3313G + 0.5B + 128 Cr = 0.5R - 0.4187G - 0.0813B + 128系数里绿色占的比重最大，这也不是随便定的，而是匹配人眼对绿光最敏感的特性。理解这一点很关键：后面所有关于“色度子采样”的取舍，根源都在这里。如果你的图是纯色块、UI 界面、线条图标，色度信息占比极高，这时候还硬上 4:2:0，边缘就会出现彩色噪点；如果是风景人像，色度砍一半几乎看不出来。
还有一个容易被忽略的细节：转换之后、做变换之前，每个通道的数值要减去 128 做电平偏移，把取值范围从 0~255 平移到 -128~127。目的是让数据围绕零点分布，这样后面的变换在数学上更对称，直流分量不会顶在一个很大的偏置上。这一步不丢信息，但如果你自己写编码器时忘了它，解码出来的图会整体偏色。
1.2 8×8 分块与 DCT：为什么要切成一格一格
接下来图像被切成一个个 8×8 的小方块，每个通道独立处理，块与块之间不重叠。为什么是 8 而不是 16 或 32？这是当年算力和压缩效率折中的结果：块越大，频域分辨率越高、压缩潜力越大，但计算量和块效应带来的视觉破坏也越明显；块太小则压缩收益不够。8×8 在 1992 年定标准时的硬件条件下是个甜点，一直沿用至今，也成了 JPEG 最典型的“指纹”。
每个 8×8 块做二维离散余弦变换（DCT），把空间上的 64 个像素值映射成 64 个频率系数。左上角那个是直流分量（DC），代表整块的平均亮度；越往右下走频率越高，代表越细致的纹理和边缘。变换本身是可逆的、无损的，它只是换了个描述方式，把“这块区域有多亮、有多少细节”表达得更适合压缩。
打个比方，DCT 就像把一段乐曲拆成不同音高的分量。你听到的是混合在一起的声音，拆开之后变成“低音多强、中音多强、高音多强”的一组数字。绝大多数自然图像的能量都集中在低频，高频系数往往很小甚至接近零，这就给了后面“把小的扔掉”的机会。这也是为什么 JPEG 对大面积平滑区域压缩率惊人，而对满是细密纹理的图束手无策。
1.3 量化表才是真正的画质开关，质量参数只是它的缩放器
真正决定画质损失的是量化这一步：把 64 个 DCT 系数分别除以量化表里对应的数值，然后四舍五入取整。量化表也是一张 8×8 的表，低频位置数值小（除得细），高频位置数值大（除得粗）。除法之后再取整，小数部分就永久消失了，这部分信息再也找不回来，这就是 JPEG 有损的根源。
标准里给了两张基准量化表，一张给亮度、一张给色度，色度那张整体数值更大，也就是砍得更狠。你设定的 quality 参数并不直接等于任何一张表，而是用来生成一个缩放因子，再去乘基准表。以常见的实现为例，规则大致是这样：
| 质量参数范围 | 缩放因子计算 | 效果 |
|---|---|---|
| quality ≥ 50 | scale = 200 - 2 × quality | q=90 时 scale=20，量化表被压到基准的约 20% |
| quality < 50 | scale = 5000 / quality | q=25 时 scale=200，量化表被放大约 2 倍 |
| 最终取值 | (基准值 × scale + 50) / 100，钳制在 1~255 | 保证不会出现 0，避免除零 |
从这张表能看出一个反直觉的事实：质量参数在 50 以下和 50 以上是两套完全不同的曲线。50 以上是线性收缩，50 以下是反比放大，所以从 60 降到 40 的破坏，远比从 90 降到 80 剧烈得多。我在做批量压缩时有个习惯：先确认业务能接受的下限，然后只在这个下限附近做微调，绝不在 50 上下反复试探，因为那个区间的画质变化不是渐进的，是断崖式的。
量化之后，64 个系数按 Z 字形顺序重排成一维序列，从低频走到高频。这个扫描顺序很讲究，它让连续出现的零聚在一起，后面用游程编码就能用很短的一串数据表示“后面这一堆全是零”。最后 DC 系数做差分（跟前一块的 DC 相减）、AC 系数做游程加 Huffman 编码，得到最终的比特流。整个链条里，量化是唯一不可逆的环节，其余步骤都是无损的数学变换。
2. 质量参数不是线性刻度，别拿它当百分比用
“质量 80”听起来像是保留了 80% 的信息，这个联想会害死人。它既不对应信息保留率，也不对应文件体积比例，甚至连画质的主观感受都不是线性的。我见过太多团队把 quality 写死成 75 或者 80，然后在某批特殊素材上翻车，回头才发现问题不在参数本身，而在于没人搞清楚这个数字到底在调节什么。
2.1 q=80 和 q=90 的实际差距，比你以为的大
我在一批中等复杂度的照片素材上做过对比，同一张 4000×3000 的风景照，用同一套编码器、同样的色度设置，只改质量参数，结果大致是这样：
| 质量 | 相对体积 | 主观观感 |
|---|---|---|
| 95 | 约 100%（基准） | 几乎与原图无差别，放大到 200% 才见轻微噪点 |
| 90 | 约 55%~65% | 正常观看无差别，专业屏幕下高频细节略软 |
| 85 | 约 40%~45% | 缩略图级别完全够用，大图看天空渐变有轻微色带 |
| 75 | 约 25%~30% | 明显可见块效应，边缘出现轻微振铃 |
| 60 | 约 15%~18% | 纹理糊成一片，只适合做背景或占位图 |
这组数字不是绝对标准，不同编码器、不同内容差异很大，但趋势是可靠的：从 95 降到 90，体积砍掉近四成，画质损失微乎其微，这是性价比最高的一段；从 85 降到 75，体积又能砍掉三分之一，但画质开始进入“能看出来”的区间；再往下走，体积收益递减，破坏却加速。
所以我的默认策略是：面向屏幕展示的图片，质量 82~88 之间找一个点；面向缩略图/列表页的，质量 70~75 足够；任何需要后续再编辑的中间产物，质量不低于 92。这个划分不是拍脑袋，而是根据“这张图会被怎么使用”反推的，比统一写死一个数值靠谱得多。
2.2 内容类型决定敏感度，同一套参数不能通吃
同样质量参数下，不同内容的受损程度差了好几倍。这是我在批量处理时踩得最狠的坑：一批图里混着商品照片、带文字的横幅、纯色背景的图标，用同一套参数跑完，照片看着挺好，文字边缘已经长出彩色毛边了。
| 内容类型 | 对 JPEG 的耐受度 | 主要破坏形式 | 建议 |
|---|---|---|---|
| 自然风景、人像 | 高 | 高频纹理变软，天空出现色带 | q 80~88 即可 |
| 商品白底图 | 中 | 白底与物体交界处出现灰边 | q 88~92，慎用强色度降采样 |
| 含文字的截图/横幅 | 低 | 笔画边缘振铃、彩边、糊字 | 尽量不用 JPEG，或 q ≥ 95 |
| UI 界面、图标 | 极低 | 色块渗色、直角变圆 | 换 PNG 或无损格式 |
| 大面积渐变 | 低 | 台阶状色带 | 降低压缩强度或加轻微噪点抖动 |
带文字的图像尤其典型。文字是高频信号，笔画边缘在频域上能量分布很广，量化表一砍，边缘就出现“振铃”——像敲钟之后的余音，在黑色笔画两侧荡出一圈浅灰色的波纹。这不是编码器写坏了，是数学上必然的结果。色度降采样还会在彩色文字上叠加一层彩边，红字周围泛绿、蓝字周围泛黄，非常刺眼。
2.3 想压体积，先动尺寸再动质量
大部分人优化图片体积的第一反应是拉低质量参数，这其实是效率最低的做法。一张 4000×3000 的图，缩到 1200×900，像素数量降到原来的 9%，哪怕质量提到 90，最终体积也远小于原尺寸配质量 70。因为 JPEG 的体积大致随像素数线性增长，而质量参数的影响是指数型的，两者的杠杆完全不在一个量级。
我处理线上图片的固定顺序是：先按展示尺寸裁剪缩放 → 再选格式 → 再调质量 → 最后剥元数据。顺序颠倒的话，你会在一张几千万像素的图上反复试参数，纯属浪费算力。顺便说一句，缩放算法也有讲究：缩小图片时用双三次或 Lanczos，比默认的最近邻或双线性效果好很多，尤其在细密纹理上，能少掉一层锯齿，后面压缩时也更容易压。
还有一个反直觉的技巧：给大面积渐变区域加一点点极轻微的噪点（幅度 1~2 个灰阶），再压缩，反而能抑制色带。原理是抖动把量化台阶打散了，人眼对随机噪点的容忍度远高于规则条纹。这个手法在做深色背景图、天空图时特别有用，代价是体积会略微上升。
3. 同一个 .jpg 后缀，内部可能是四种完全不同的东西
拿到一个 .jpg 文件，不代表你知道它里面是什么。色度采样比例、是否渐进、重启间隔、熵编码方式，这些参数组合起来能产生观感差异巨大的结果。排查线上问题时，光看后缀完全不够，得把文件头扒开看。
3.1 基线式与渐进式：首屏体验的分水岭
基线（Baseline）编码从上到下按行扫描，一次传完，浏览器拿到多少就能画多少，但必须等全部数据到齐才算完整。渐进式（Progressive）把图像分成多次扫描，第一遍只传低频概貌，后面几遍逐层补充细节。在慢网络下，渐进式的体验优势非常明显：用户先看到一个模糊的整体轮廓，然后再逐渐清晰，而不是顶部已经清晰、底部还是一片空白。
代价是解码开销更高。渐进式文件在解码时需要把整个系数矩阵缓冲在内存里，反复扫描填充，移动端解码耗时可能比基线高出三到五成，内存占用也更大。所以选择要看场景：
- 大图、首屏展示、网络条件不确定：用渐进式。
- 小图、图标、需要频繁解码的列表页：用基线式。
- 服务端会做二次处理的中间文件：用基线式，避免反复扫描。
文件体积上，渐进式通常比基线略小一点（因为扫描之间的统计可以利用），但差异一般在几个百分点，不足以作为决策依据。
3.2 4:4:4、4:2:2、4:2:0：色度到底该砍多少
这是影响观感最直接、也最容易被忽略的参数。它的含义是亮度与色度的采样比例：
| 采样模式 | 含义 | 体积影响 | 适用场景 |
|---|---|---|---|
| 4:4:4 | 每个像素都有独立的 Y/Cb/Cr | 最大 | 文字图、精细图形、需要后续抠图的素材 |
| 4:2:2 | 水平方向色度减半，垂直保留 | 中等 | 高质量展示图、彩色边缘敏感的素材 |
| 4:2:0 | 水平和垂直色度都减半 | 最小 | 普通照片、缩略图、背景图 |
4:2:0 是绝大多数编码器的默认值，因为它在自然照片上几乎看不出差别。但它在两类图上会立刻露馅：一是彩色文字，二是高饱和度的细线条。红色文字配 4:2:0，笔画周围会渗出绿边，因为色度信息被平均到了相邻像素上。我遇到过一批带红色标签的商品图，用默认参数处理后，标签边缘全是绿色毛刺，客户直接投诉，最后把采样改成 4:4:4 才解决。
这里有个实用的判断方法：把图片放大到 200%，盯着两种高对比颜色的交界处看。如果交界处出现了第三种颜色（既不是这边的也不是那边的），说明色度已经被平均污染了，这时候就该考虑提高采样精度。
3.3 重启间隔与容错：不只是为了抗损坏
重启间隔（Restart Interval）指的是每隔多少个 MCU 块插入一个重启标记，重置一次编码状态。默认通常是 0（不插入），文件是一个连续的整体。设置重启间隔有两个好处：一是数据损坏时只会影响一段，不会整图花掉；二是解码时可以并行处理，多核场景下更快。
代价是每个重启段都要重新写一次 Huffman 表和预测值，体积会略微增加，一般在 1% 以内。对于需要通过网络传输、可能被截断的场景，设一个合理的重启间隔是划算的。我在做移动端大图加载时，会把间隔设成每行 MCU 数量，这样即使传输中断，已到达的部分也能解出一半左右的可用图像。
顺带提一句熵编码。标准里定义了 Huffman 和算术编码两种，算术编码压缩率能再高 5%~8%，但历史上因为专利问题长期被冷落，很多编码器默认关闭。现在多数开源实现已经支持，如果你的工具链允许，开启算术编码是个几乎零成本的收益，只是要注意老旧的解码器可能不支持。
4. 把参数捏在手里：几套可直接抄的代码
原理讲完，落到操作。下面这几段是我日常真在用的，覆盖 Python 单张处理、OpenCV 场景、命令行批量、以及自定义量化表这种稍微进阶的玩法。每段都标了踩过的坑。
4.1 Pillow：参数最全，但要小心默认值
Pillow 的save方法对 JPEG 暴露的参数相当完整，是精细控制的首选：
from PIL import Image im = Image.open("source.png").convert("RGB") im.save( "out.jpg", format="JPEG", quality=85, # 质量因子 subsampling=2, # 0=4:4:4, 1=4:2:2, 2=4:2:0 optimize=True, # 重新计算 Huffman 表，体积通常降 2%~5% progressive=True, # 渐进式 dpi=(72, 72), )几个必须知道的点：
convert("RGB")不能省。原图如果是 RGBA 或 P 模式，直接存 JPEG 会报错，因为 JPEG 不支持透明通道。subsampling的默认值是 -1，表示“沿用图像原有设置”，但新开的图没有原有设置，实际会退化成 4:2:0。想要 4:4:4 必须显式写 0，别指望默认。optimize=True只是优化熵编码阶段的码表，不改动量化，所以是纯赚，没有画质代价。代价是编码时间变长，批量处理时能明显感觉到。quality的默认值是 75，很多人以为不传就是“原样保存”，实际上是被默默压了一遍。
如果要精确控制量化表，可以传qtables参数，格式是长度 64 的列表（按自然顺序排列，不是 Z 字形顺序），或者传两个列表分别给亮度和色度。这个用法在需要“锁定画质下限”的场景很有价值，比如你要保证某批图的量化强度完全一致，不受编码器版本影响。
# 用一张统一的自定义量化表，保证跨批次一致性 flat_table = [16] * 64 im.save("out.jpg", qtables=[flat_table, flat_table])4.2 OpenCV：默认质量 95，别以为它很“省”
OpenCV 的imwrite用起来最省事，但也藏着坑：
import cv2 img = cv2.imread("source.png") # 默认读成 BGR 三通道，alpha 直接丢 cv2.imwrite( "out.jpg", img, [int(cv2.IMWRITE_JPEG_QUALITY), 85], )第一个坑是默认质量是 95，不是 75。这意味着你用 OpenCV 随手存一张图，体积会比你预期的大不少，尤其是批量导出时，磁盘和带宽都会莫名其妙地多花。第二个坑是imread默认按彩色三通道读，带透明的 PNG 会被静默丢掉 alpha 通道，如果你的下游流程依赖透明度，这里就已经出错了。要么用cv2.IMREAD_UNCHANGED读取后再自己判断，要么在流程入口就断言格式。
第三个坑是通道顺序。OpenCV 内部是 BGR，如果你把 PIL 读出来的 RGB 数组直接丢给imwrite，红蓝会互换，肤色变青、天空变橙。做跨库数据传递时，务必在边界处统一做一次cv2.cvtColor(img, cv2.COLOR_RGB2BGR)，并且养成在保存后抽查一张的习惯。
OpenCV 还支持IMWRITE_JPEG_OPTIMIZE和IMWRITE_JPEG_PROGRESSIVE，但它们的值取决于编译时的后端，跨平台行为不完全一致。需要精确控制时我还是更倾向 Pillow 或直接调命令行工具。
4.3 ImageMagick 与 ffmpeg：批量和流水线的正确姿势
单张处理用库，批量处理用命令行，这是我的分工原则。ImageMagick 的参数表达最直观：
magick source.png \ -sampling-factor 4:2:0 \ -quality 85 \ -interlace Plane \ -strip \ out.jpg-interlace Plane就是渐进式，-strip会剥掉所有元数据（EXIF、ICC、注释），体积能再降几个百分点——但要注意，剥掉 ICC 色彩配置会让广色域图片的颜色显示发生变化，做电商图时千万别顺手加这个参数。-sampling-factor的写法是4:2:0、4:2:2、1x1（等价于 4:4:4），注意最后这个写法不统一，容易写错。
批量场景用mogrify更省事，它直接原地处理：
mogrify -path ./out -resize 1600x1600\> -sampling-factor 4:2:0 -quality 85 -strip *.png-resize 1600x1600\>里的\>表示“只在原图更大时才缩小”，这个符号很容易漏，漏了就会把小图放大，白白浪费体积还糊。
ffmpeg 处理视频抽帧或需要接入现有转码管线时更顺手：
ffmpeg -i input.png -q:v 4 -huffman optimal -y out.jpg-q:v的取值范围是 2~31，数字越小质量越高，跟常规的质量参数方向相反，这是最容易搞反的地方。2 大致对应质量 95 以上，4 大约对应 85，8 大约对应 70。-huffman optimal相当于 Pillow 的 optimize，值得常开。
4.4 换编码器：同样质量下再省两成体积
标准 JPEG 编码器沿用了三十年，但编码器本身的实现这些年一直在进步。在质量参数相同的前提下，换一个更聪明的编码器，往往能在画质不降的前提下把体积再压下去一截：
| 编码器类型 | 特点 | 适用场景 |
|---|---|---|
| 标准实现 | 兼容性最好，速度最快 | 通用场景、需要绝对兼容 |
| 优化型实现 | 同样的量化表，用更聪明的 Huffman 与迭代策略 | 静态资源、CDN 分发 |
| 感知优化型 | 按人眼敏感度调整量化，速度极慢 | 少量精品图、首屏大图 |
| 新一代编码器 | 引入更好的色度处理和块划分 | 对体积敏感的新项目 |
感知优化型的思路值得一提：它不追求数学误差最小，而是追求“人眼看起来最像”。在同样的体积下，它会把比特更多地分配给视觉上敏感的区域，牺牲掉那些反正看不出来的高频噪声。代价是编码时间可能是标准实现的上百倍，所以只适合对少量关键图片做一次性处理，不适合放进实时管线。
选取编码器时还要考虑解码端的兼容性。越新的编码器，生成的比特流越可能包含老解码器不认识的特性（比如某些扩展标记），虽然在主流浏览器上没问题，但在一些嵌入式设备、老旧打印机、工业相机上可能直接打不开。我的经验是：面向公网的资源用优化型实现，面向内部系统或特定硬件的，老老实实用标准实现。
5. 反复另存、旋转、加元数据：那些让文件莫名其妙变大的操作
“这张图我什么都没改，就是打开又保存了一下，怎么大了三倍？”这个问题我在不同团队里被问过至少五次。原因往往不在压缩本身，而在整个处理链条上那些默认开启、没人注意的附加动作。
5.1 代际损失：每存一次就掉一层皮
JPEG 的压缩是有损的，解码出来的像素已经不是原始像素，再编码一次就是在“近似值”的基础上再近似一次，误差会累积。这就是代际损失。我在一张包含文字和细纹理的测试图上做过连续重编码实验，每次都保持质量 90：
| 重编码次数 | 观感变化 |
|---|---|
| 1 次 | 与原图基本无差别 |
| 3 次 | 文字边缘开始出现轻微毛刺 |
| 5 次 | 细纹理明显糊化，边缘振铃可见 |
| 10 次 | 块效应成片出现，彩色噪点明显 |
质量参数越低，累积速度越快。用质量 75 连续存五次，破坏程度就赶上质量 90 存十几次。这也解释了一个常见现象：一张图在设计、运营、审核几个环节之间来回传，每人都“另存为”一次，最后拿到的版本比原始版本糊了一大截，但没人觉得自己做错了什么。
规避方法很朴素：中间环节一律存无损格式（PNG 或 TIFF），只在最终交付时转成 JPEG。如果工作流里必须用 JPEG 传递，那就把质量拉到 95 以上，把损失压到最低。另外，能改元数据就不要重编码——旋转、加标签、改描述这些操作，很多工具支持直接改文件头而不动像素数据，用这类方式处理能完全避免代际损失。
5.2 旋转一张图，为什么体积暴涨
这是最经典的坑。某些图片查看器在“旋转”图片时，实际做的是解码 → 像素重排 → 重新编码，而且用的是默认质量（通常 90 左右，甚至更高）。你只是想让图片正过来，结果体积翻了一倍，画质还降了一档。
更隐蔽的是，有些工具旋转时不重编码，只修改 EXIF 里的 Orientation 标记，文件大小几乎不变，但不同软件对这条标记的解读不一致：有的会按标记旋转显示，有的直接忽略，于是同一张图在不同地方看到的方向不一样。这两种行为混在一起，就会出现“我这边是正的，用户那边是倒的”这种诡异 bug。
我的处理原则是：涉及方向的批处理，统一用支持无损旋转的工具做，并在处理完之后把 Orientation 标记归位为 1。如果用 ImageMagick，-auto-orient会先按标记摆正，然后再做后续操作，配合-strip把标记清掉，行为就确定了。如果用代码处理，务必在保存前显式把 Orientation 置为 1，否则下游还会再转一次，转成歪的。
5.3 EXIF、ICC、缩略图：藏在文件里的“隐形体积”
一张手机拍的照片，像素数据可能只占文件的一半，另一半是各种附加信息：拍摄参数、GPS 坐标、厂商信息、色彩配置、还有一张内嵌的缩略图。这张缩略图本身也是一张 JPEG，通常几十 KB，很多人根本不知道它存在。
| 元数据类型 | 典型体积 | 是否建议保留 |
|---|---|---|
| 拍摄参数（光圈、快门等） | 几 KB | 视业务而定 |
| GPS 坐标 | 几百字节 | 涉及隐私，务必剥离 |
| ICC 色彩配置 | 几百字节到几 KB | 广色域图必须保留 |
| 内嵌缩略图 | 10~50 KB | 展示场景可剥离 |
| 厂商私有段 | 不定，可能很大 | 建议剥离 |
这里有个必须提醒的点：ICC 配置不能无脑剥。如果原图是广色域（比如某些相机或设计软件导出的），剥掉 ICC 之后，浏览器会按 sRGB 解读，颜色会明显发灰、发暗，红色变得特别扎眼。表现形式就是“这张图在我电脑上好好的，上传之后颜色不对了”。排查这类问题时，第一步就该用工具把元数据打印出来看，而不是怀疑压缩参数。
exiftool -a -G1 -s image.jpg这条命令会把所有元数据段分组列出来，包括色彩空间、方向标记、是否内嵌缩略图。养成转码前后各跑一次的习惯，能省掉大量扯皮。
5.4 打开是黑的、颜色是反的：CMYK 的坑
偶尔会遇到一种情况：图片在某个软件里打开一切正常，换一个软件打开就变成反色或者一片黑。这类问题十有八九是 CMYK 色彩空间的 JPEG。印刷行业常用 CMYK，但网页和大多数图像库只认 RGB，遇到 CMYK 数据时会按 RGB 解读，四个通道被强行塞进三个通道，结果就是颜色彻底错乱。
判断方法很简单，看文件里的色彩空间标记和 Adobe 段。处理方式也简单：在转码入口统一做一次色彩空间归一化，把所有输入都转到 sRGB，再进行后续操作。这一步放在管线最前面，比在出口处一个个修要省事得多。我在接手任何图像处理项目时，第一件事就是确认入口有没有做这个归一化，没有的话先补上，能挡掉后面一大半的“颜色不对”工单。
6. 什么图不该存成 JPEG：一份判断清单
JPEG 是通用格式，不是万能格式。有些内容天生跟它的压缩模型犯冲，硬用只会得到又大又糊的结果。下面这套判断逻辑是我在实际项目里反复用下来的，基本能覆盖九成场景。
6.1 截图、UI、线条图：振铃的重灾区
任何以“规则边缘 + 大面积纯色”为主的内容，都是 JPEG 的噩梦。UI 截图、图表、线稿、二维码、带文字的横幅，这些图的能量高度集中在高频，量化一砍就是满屏毛刺。而且这类图的颜色数量少，PNG 的调色板压缩能把它们压到极小，往往比 JPEG 还小，画质还是无损的。
我做过一组对照：一张 1920×1080 的界面截图，存 PNG 是 180KB，存 JPEG 质量 90 是 240KB，质量 75 是 110KB 但文字已经糊了。也就是说，JPEG 在低质量下体积确实更小，但代价是文字不可读；想要画质可接受，体积反而比 PNG 大。这种情况下用 JPEG 是纯亏。
判断标准可以简化成一句话：如果这张图放大后会看到清晰的直角和纯色块，就别用 JPEG。
6.2 需要透明通道的图，JPEG 从根上不支持
这一点没什么可商量的。JPEG 标准里没有 alpha 通道，任何带透明的图存成 JPEG，透明区域要么变成白色，要么变成黑色，取决于编码器的填充策略。有些工具会默默填白，有些填黑，还有些直接报错。如果你的设计稿里有投影、圆角、镂空，转 JPEG 之后这些细节全部变成硬边或者色块。
替代方案要看用途：需要无损透明就用 PNG，需要小体积透明就用支持 alpha 的现代格式，两者都不行的话，就只能在设计层面妥协——把透明区域预先合成到一个确定的背景色上，再存 JPEG。这个背景色必须跟最终展示环境的底色一致，否则边缘会出现一圈异色描边。
6.3 一套组合拳：把体积压下去的正确顺序
综合前面所有内容，我给出一套我日常用的处理流程，按顺序执行，每一步都有明确目的：
- 归一化输入：统一转 sRGB，处理掉 CMYK 和异常色彩空间。
- 按展示尺寸缩放：这是体积收益最大的一步，用 Lanczos 重采样。
- 判断内容类型：照片类走 JPEG，图形/文字类走无损格式。
- 选采样比例：普通照片 4:2:0，含彩色细节的用 4:2:2 或 4:4:4。
- 定质量参数：在 82~88 之间按内容微调，不要低于 75。
- 开优化：启用熵编码优化，纯赚。
- 剥元数据：去掉 GPS、厂商段、内嵌缩略图，保留必要的 ICC。
- 抽检：随机取几张放大到 200% 看边缘，确认没有振铃和彩边。
这套流程里，第 2 步和第 3 步贡献了绝大部分体积收益，第 5 步只是精细化调整。很多团队把精力全花在调质量参数上，却忽略了缩放和格式选择，属于典型的抓小放大。
6.4 排查表：体积异常、画质异常、显示异常怎么定位
最后给一张速查表，遇到问题时按这个顺序排查，比漫无目的地改参数快得多：
| 现象 | 最可能的原因 | 验证方式 | 处理 |
|---|---|---|---|
| 体积比预期大很多 | 质量默认值偏高，或元数据未剥离 | 打印 EXIF 和量化表 | 显式设质量，剥无用段 |
| 另存后体积暴涨 | 触发了重编码，且用了默认高质量 | 对比前后量化表 | 改用无损中间格式 |
| 文字边缘有彩边 | 色度降采样过强 | 放大看高对比交界处 | 改 4:4:4 或 4:2:2 |
| 大面积渐变有色带 | 量化过强 + 无抖动 | 看天空、暗部过渡 | 提高质量或加轻微噪点 |
| 颜色整体发灰发暗 | ICC 被剥离或色彩空间未归一 | 检查 ICC 段是否存在 | 保留 ICC 或统一转 sRGB |
| 换个软件打开变反色 | CMYK 数据被按 RGB 解读 | 看色彩空间标记 | 入口统一转 sRGB |
| 方向不一致 | Orientation 标记与像素数据冲突 | 检查方向标记值 | 无损旋转后归位为 1 |
| 上传后比本地糊 | 服务端二次压缩且参数未知 | 下载回来对比量化表 | 提高上传质量或改无损 |
这张表里，我个人踩得最多的是“服务端二次压缩”这一条。本地看着完美的图，上传之后明显变糊，排查半天发现是中间层又压了一遍，而且用的是默认参数。这类问题的根源不在技术，在于链路上没人对“这张图被压了几次”负责。后来我们的做法是在文件里埋一个自定义标记，每次处理都追加一条记录，出问题时直接把标记读出来，一眼就知道经过了几道手。
说到底，JPG/JPEG 这套格式用了三十多年还在被广泛使用，不是因为它先进，而是因为它在压缩比、兼容性、计算成本之间找到了一个极其耐用的平衡点。真正用好它的关键，不在于记住几个推荐参数，而在于脑子里有一张清晰的图：知道它在哪里丢信息、为什么丢、丢多少你能接受。想清楚这三件事，剩下的参数调整都是水到渠成的事。我自己现在的习惯是，每接一个新的图片处理需求，先花十分钟确认内容类型和展示环境，再动手写代码，这十分钟往往能省掉后面几轮返工。
