1. 先把“图片 jpg 格式怎么转换”这件事想明白
图片 jpg 格式怎么转换，这个问题我一年至少被问二十次。问的人里，有做电商要给商品图统一发平台的，有做自媒体的要把一堆截图塞进文章里的，也有做开发的同学在批处理接口里被“格式不对”卡住的。大家的诉求都指向同一个动作：把手上某种格式（png、webp、bmp、tiff、heic 等等）的图片，变成能被目标系统接受的 jpg。听起来是个一行命令的事，但真正做起来，你会发现每个人转完之后的效果天差地别：有人转出来 200KB 清晰如初，有人转出来 2MB 还糊。差别不在工具，而在“你到底知不知道自己在做什么”。
先给个直白结论：jpg（规范写法是 JPEG）是一种有损压缩的位图格式，它用丢弃人眼不敏感的高频信息来换体积。这个特性决定了它天生适合照片、渐变、实拍图，不适合线条锐利的图标、带文字的截图、需要透明背景的元素。转换动作本身不难，难的是转换前后的三件事：质量参数怎么定、透明通道怎么办、元数据和色彩配置会不会丢。这三点想清楚，你才算是真的会“转换”，而不是按住一个按钮碰运气。
这篇文章面向三类人：完全零基础、只想把手上一两张图搞定的普通用户；需要一次处理几百上千张图的运营、设计、内容岗；以及要在代码里把转换能力做成自动化流程的开发者。我会把四种主流做法从“系统自带工具”一直讲到“自己写脚本批处理”，中间穿插参数推导、体积估算、踩坑记录。你可以按自己的场景跳着看，也可以从头顺一遍，因为后面脚本里用的参数，很多都是从前面那些原理推出来的。
1.1 jpg 到底是个什么样的格式
我把 JPEG 的压缩过程拆成四步来讲，不用记公式，但记住这个链路对你选参数有直接帮助。第一步是颜色空间转换，把 RGB 转成亮度加两个色度分量（YCbCr）。人眼对亮度敏感、对色度迟钝，这就是后面能大刀阔斧砍色度信息的生理学基础。
第二步是分块与离散余弦变换，图像被切成 8×8 的小块，每块做 DCT，把空间上的像素值变成频率域上的系数。低频系数代表大片平缓的颜色过渡，高频系数代表边缘和细节。
第三步是量化，这是唯一真正“丢信息”的环节。量化表里每个系数除以一个步长再取整，高频用大步长（粗暴取整，大量归零），低频用小步长（精细保留）。我们平时说的“质量 85”“质量 80”，本质就是对标准量化表做一个整体缩放。质量数字越大，步长越小，保留的细节越多。
第四步是熵编码，把量化后的系数用霍夫曼编码压成比特流，这一步是无损的。另外文件里还包含各种标记段：量化表、霍夫曼表、EXIF、ICC 色彩描述文件、缩略图等等。
这里有个大家在文档里不太容易看到的点：质量参数不是标准量纲。它不是“保留 85% 信息”的意思，而是“按某个系数缩放量化表”。不同编码器实现（各类开源库、各家图像软件、手机系统）对同一个 q 值可能给出明显不同的结果。所以你在 A 工具里习惯了 q=80，换到 B 工具里可能得用 q=85 才等效。我遇到过最离谱的一次，同一个值在两个工具间体积差了将近 40%，排查半天最后发现是色度子采样的默认值不一样。
1.2 什么场景该转，什么场景千万别转
先说该转的。照片类素材几乎无脑转 jpg：手机实拍、相机出片、商品实拍、风景人像，这些内容的高频信息本来就少，压缩比可以做到 10:1 甚至 20:1 而肉眼无感。需要广泛兼容的交付场景也该转：老系统、老打印机、某些投稿系统、部分网页后台的上传控件，对 png 和 webp 的支持都不可靠，jpg 是通行证。
再说别转的。带文字的截图转 jpg 是最常见的错误操作。文字是典型的锐利边缘，属于高频信息密集区，量化时被砍得最狠，结果是笔画发虚、边缘出现“蚊子噪点”，再叠加色度子采样，彩色文字边缘还会渗出色斑。这类图应该留在 png，或者至少把子采样关掉。
需要透明背景的图转 jpg 会强制丢掉 alpha 通道，透明区域要么变黑要么变白（取决于工具默认行为），这个损失是不可逆的——你以为转换完还能转回来？不能，alpha 信息在写入那一刻就没了。
还有一个容易被忽略的场景：已经是 jpg 的图再转一次 jpg。很多人为了“压缩一下”，把一张 jpg 重新用低质量保存，然后再来一次。每重编码一次就再量化一次，误差累积，画质是阶梯式下降的。如果源文件已经是 jpg 且质量不低，正确做法是只做尺寸缩放或元数据清理，不要重编码，或者至少用不低于原图质量的参数。
2. 转换前的参数功课：质量、色彩、透明通道
2.1 质量参数 q 到底怎么选
这是被问得最多的问题，也是最能体现“会不会”的地方。我给一个经验区间表，这是我用几百张不同类型的图反复试出来的粗略规律，只能当参考，不能当定律，因为具体体积跟图像内容的复杂度强相关。
| 质量参数 | 相对体积（以 q95 为基准） | 主观观感 | 建议用途 |
|---|---|---|---|
| 95 | 100% | 几乎无法与源图区分 | 需要二次编辑的中间稿 |
| 90 | 约 70% | 放大到 200% 才看得出差异 | 高质量交付、印刷前预览 |
| 85 | 约 55% | 正常观看无感 | 电商主图、作品集 |
| 80 | 约 45% | 细节略软，整体扎实 | 网页正文配图 |
| 70 | 约 32% | 平滑区域出现轻微块状 | 列表缩略图、移动端 |
| 60 | 约 25% | 压缩痕迹明显 | 仅用于占位、临时预览 |
| 40 以下 | 20% 以内 | 大面积色带和方块 | 不建议用于任何正式场景 |
怎么用这张表？先判断你的图最终呈现在多大的尺寸上。如果一张 4000 像素宽的原图最终在网页上只显示 800 像素宽，那你完全没必要为了保质量把 q 拉到 95——先缩放到 1000 像素左右，再用 q=80，得到的结果比“原尺寸 q=95 再让浏览器缩放”要小得多、也清楚得多。这个顺序很多人搞反了：先缩放再编码，不要先编码再指望显示端帮你缩。
想粗估体积，可以套一个很土但能用的算式：预测体积 ≈ 宽 × 高 × 每像素比特数 ÷ 8。照片在 q=85 时，每像素比特数大约落在 0.5 到 1.2 之间；内容越复杂（树叶、毛发、噪点多的夜景）越靠近上限，越简单（天空、纯色背景人像）越靠近下限。举个例子，3000×2000 的图，取 0.8 bit/pixel，就是 3000×2000×0.8÷8 ≈ 600KB。这个数能帮你在动手前判断“目标体积能不能达到”，避免反复试。
还有一个常被忽略的开关：色度子采样（subsampling）。默认通常是 4:2:0，即每 2×2 个像素共用一个色度采样点，色度数据量直接砍到四分之一。这是 jpg 体积小的大功臣，但也是彩色文字边缘渗色的元凶。如果图里有大量小字、细线条、彩色图标，建议改成 4:4:4（不采样），体积会增加大约 15% 到 30%，但边缘干净得多。我处理带标注的产品图时会固定用 4:4:4，那个体积换清晰度是值的。
2.2 透明背景、色彩模式、EXIF 这三个坑
透明通道。png 里带 alpha 的图直接存 jpg，不同工具的行为不一样：有的报错，有的静默变黑，有的静默变白。正确姿势是显式地把 alpha 合成到一个底色上，底色常见选白（电商、文档）或选与页面一致的背景色。合成公式说白了就是按 alpha 做加权：结果 = 前景 × α + 底色 × (1-α)。别指望工具替你猜，猜错一次返工一批。
色彩模式。除了 RGBA，还要注意调色板模式（P 模式）和灰度模式（L）。P 模式带透明索引，直接转 jpg 会有意外；CMYK 模式的图（常见于印刷来稿）转 RGB 再转 jpg 才安全，否则某些工具会写出颜色怪异的文件。我的习惯是：转换前统一convert("RGB")或先转 RGBA 再合成，路径单一，结果可预期。
EXIF 方向标签。手机拍的照片经常在 EXIF 里写着“这张图应该旋转 90 度显示”，而像素数据本身是横着的。看图软件会读这个标签自动转正，但你的转换脚本如果不处理，写出来的 jpg 可能就是躺倒的。批处理时这个问题特别隐蔽——你在电脑上看缩略图是正的，上线之后全歪了，回头查半天。解决办法是在读取后立刻做一次“按 EXIF 方向矫正”，把像素真正转正，然后再进入后续流程。
ICC 色彩描述文件。专业相机和设计稿常带 ICC，告诉软件“这些 RGB 数值属于哪个色彩空间”。转 jpg 时如果把 ICC 丢了，在广色域屏幕上会明显偏色（通常是变淡、变灰）。日常社交媒体用图丢了问题不大，但涉及品牌色、印刷前稿，就得把 ICC 一起带过去。带 ICC 会让文件大几 KB 到几十 KB，比起返工成本，这点体积不值一提。
注意：转换前一定先确认源文件的模式、是否有透明、是否带方向标签。这三项决定了你的转换脚本要不要写特判分支，跳过这步检查，批量跑出来的结果会有一半是废的。
3. 四条实操路线：从单张到批量
3.1 零基础路线：系统自带工具和在线工具
如果你只有一两张图，完全没必要装环境写代码。系统层面其实都有现成能力。
macOS 自带的sips是个被严重低估的命令行工具，一行就能转：
sips -s format jpeg -s formatOptions 85 input.png --out output.jpgformatOptions就是质量参数，取值 0 到 100。这个命令的好处是零安装、能写进脚本循环，缺点是它对透明通道的处理比较“自作主张”，遇到带 alpha 的图建议先手动合成底色。
Windows 上如果没有第三方工具，可以用 PowerShell 调系统自带的图像接口：
Add-Type -AssemblyName System.Drawing $img = [System.Drawing.Image]::FromFile("C:\path\in.png") $img.Save("C:\path\out.jpg", [System.Drawing.Imaging.ImageFormat]::Jpeg) $img.Dispose()这里有个必须知道的事：这个接口不接受质量参数，它用的是固定默认值（大约相当于质量 75），画质和体积你都控制不了。所以它只适合“能用就行”的场景，正式交付别用它。想控制质量得走编码器参数那一套，代码会长不少，性价比不如直接上跨平台工具。
图形界面的话，任何一款图像编辑软件都有“另存为 / 导出为”的选项，导出面板里一般能找到质量滑块、子采样、是否保留元数据这些开关。注意区分“保存”和“导出”：保存可能直接覆盖源文件，批量处理前务必确认输出路径，我有过一次手滑把一批 png 原图覆盖成 jpg，源文件彻底没了。
在线转换网站能用但要看场合。上传即转换的站点适合公开素材、非敏感图；任何带身份信息、合同、未发布设计的图，都不应该往线上传。另外很多站点在服务端会统一用较低质量重编码，你拿回来的图和原图可能已经不一样了，且没有任何提示。
3.2 开发者路线：Python 批量脚本，一次写完全年用
要处理成百上千张图，脚本是唯一正确选择。Python 生态里最省事的是 Pillow，安装就一句pip install pillow。
先给一个最小可用版本，把前面讲的所有坑都堵上：
from pathlib import Path from PIL import Image, ImageOps def to_jpg(src: Path, dst: Path, quality: int = 85, bg=(255, 255, 255), keep_icc: bool = True): with Image.open(src) as im: # 1) 按 EXIF 方向把像素真正转正 im = ImageOps.exif_transpose(im) # 2) 统一模式，处理透明与调色板 if im.mode in ("RGBA", "LA", "P"): im = im.convert("RGBA") canvas = Image.new("RGB", im.size, bg) canvas.paste(im, mask=im.split()[-1]) im = canvas elif im.mode not in ("RGB", "L"): im = im.convert("RGB") # 3) 取出 ICC，转完再塞回去 icc = im.info.get("icc_profile") if keep_icc else None # 4) 编码参数 dst.parent.mkdir(parents=True, exist_ok=True) im.save( dst, format="JPEG", quality=quality, subsampling=0, # 4:4:4，保文字边缘；照片可改 2 optimize=True, # 优化霍夫曼表，平均再省 3%~8% progressive=True, # 渐进式，网页首屏体验更好 icc_profile=icc, )这段代码里有几个决定值得解释。subsampling=0是 4:4:4，如果你确定这批全是照片，改成subsampling=2（4:2:0）能再省一截体积。optimize=True会多花一点 CPU 时间重新计算最优编码表，对批量任务来说这点开销完全可以接受。progressive=True让浏览器先加载低清轮廓再逐步清晰，对长文章里的配图体验提升明显，代价是解码时略费一点内存。
如果要的是“批量”，再套一层遍历和日志：
import csv from pathlib import Path from PIL import Image, ImageOps def batch_convert(src_dir: Path, dst_dir: Path, quality=85): exts = {".png", ".webp", ".bmp", ".tif", ".tiff", ".heic"} rows = [] for src in src_dir.rglob("*"): if not src.is_file() or src.suffix.lower() not in exts: continue rel = src.relative_to(src_dir) dst = dst_dir / rel.with_suffix(".jpg") before = src.stat().st_size try: to_jpg(src, dst, quality=quality) after = dst.stat().st_size rows.append([str(rel), before, after, "ok"]) except Exception as e: rows.append([str(rel), before, 0, f"fail: {e}"]) with open(dst_dir / "report.csv", "w", newline="", encoding="utf-8-sig") as f: w = csv.writer(f) w.writerow(["file", "bytes_before", "bytes_after", "status"]) w.writerows(rows)rglob会递归进子目录，用relative_to保留原目录结构，避免几百个文件全平铺到一起重名覆盖。最后落一份 CSV 报告，是我强烈建议加的一步——批处理最怕“跑完了但不知道哪些失败了”，有报告就能一眼看出异常，也方便事后对比压缩比是否合理。
如果这批图里有超大图（比如上亿像素的拼接图），直接Image.open可能吃光内存。这时有两个办法：一是用Image.draft()让解码器以较低分辨率解码（仅对 jpeg 源有效），二是先按目标尺寸等比缩放到安全尺寸再编码。另外记得Image.MAX_IMAGE_PIXELS这个保护机制，超过阈值会直接抛异常，正常场景别去关它，那是防内存炸弹的。
3.3 命令行路线：一行命令搞定整目录
不喜欢写 Python 的话，图像处理命令行工具是另一个选择。以常用开源工具为例，批量转换整目录：
mkdir -p out mogrify -path out -format jpg -quality 85 \ -sampling-factor 4:2:0 -strip -interlace Plane \ src/*.png几个参数值得说清楚。-strip会去掉所有元数据（EXIF、ICC、注释），体积能再省一点，但也会把方向标签和色彩描述一起删掉，所以如果源图依赖 EXIF 方向，必须先转正再 strip，顺序错了图会歪。-interlace Plane对应前面说的渐进式。-sampling-factor 4:2:0是彩色子采样，处理文字图时改成4:4:4。
还有一类场景是处理视频或动图，此时用多媒体处理工具更顺手。把静帧导成 jpg 的核心参数是质量档位：
ffmpeg -i input.png -q:v 3 -pix_fmt yuvj420p output.jpg这里的-q:v取值 2 到 31，数字越小质量越高，跟前面 Pillow 的方向完全相反，这是很多人第一次用会栽的地方。经验值：2 到 3 相当于很高质量，4 到 5 是日常够用，7 以上就明显看到压缩痕迹了。如果源图带透明通道，这条命令会因为像素格式不支持而报错或输出异常，得先合成底色。
命令行工具的优势是启动快、依赖少、适合塞进任何构建脚本和定时任务；劣势是参数风格各不相同，跨工具迁移时容易记混。我的做法是给每类任务写一个封装脚本，把参数固化在里面，用的时候只传目录，不去每次回忆这些细节。
3.4 路线怎么选：一张对照表
| 场景 | 推荐路线 | 理由 | 注意点 |
|---|---|---|---|
| 手头一两张图 | 系统命令行或图形界面导出 | 零配置，几分钟搞定 | 图形界面的“保存”会覆盖源文件 |
| 几十张、格式统一 | 命令行批量 | 一行命令，不用写代码 | 先小批量试跑，确认参数 |
| 几百上千张、需保留目录结构 | Python 脚本 | 可控性最强，能出报告 | 加异常捕获，别让单张失败中断全局 |
| 需要定期自动化 | 命令行封装 + 定时任务 | 依赖少、易维护 | 做好幂等，重复跑不产生重复文件 |
| 带透明、带文字的图多 | Python 脚本 | 需要逐图判断模式 | 强制 4:4:4，显式合成底色 |
表格里最后一行值得展开：当一批图里既有照片又有截图时，最好别用一套参数打天下。我的做法是加一个简单分流：读一下图像尺寸和边缘密度（或者干脆按文件名前缀、按来源目录），照片走 4:2:0 + q80，截图走 4:4:4 + q90。多写十行判断，换来的是整批图都不难看。
4. 批量处理的工程化细节
4.1 目录结构、命名与幂等
批处理最容易翻车的地方不是编码，是文件管理。我踩过最典型的一个坑：脚本用源文件名直接拼输出名，结果源目录里同时存在a.png和a.webp，两个都转到a.jpg，后一个静默覆盖了前一个。表面上跑完了，实际少了一张，而且要过很久才会发现。
解决思路有三条，选一条坚持用就行。第一，输出目录与源目录完全隔离，用relative_to保留结构，输出路径永远带.jpg后缀并做一次存在性检查。第二，文件名里带源格式后缀，比如a_png.jpg、a_webp.jpg，牺牲一点美观换绝对安全。第三，先算清单再执行，把所有“源到目标”的映射先跑一遍，检测目标路径冲突，有冲突就报错退出，一个文件都不动。
幂等也很重要。如果你把转换做成定时任务，同目录重复跑要保证结果一致、不产生a.jpg、a_1.jpg、a_2.jpg这种堆积。做法是：写入前先写到临时文件（比如a.jpg.tmp），成功后再原子重命名覆盖目标；已经存在且源文件修改时间未变的目标直接跳过。这样任务中断也能安全重跑，不用人工清理。
另外提醒一下中文路径。大部分现代工具和库都支持 Unicode 路径，但少数命令行工具在特定终端编码下会出问题。稳妥做法是尽量用 ASCII 目录名，或者确认工具链的编码设置一致。我之前有个批处理在本地跑得好好的，放到另一台机器上就报“找不到文件”，最后发现是路径里的中文字符被按不同编码解释了。
4.2 并行、进度与失败重试
图多的时候单线程会很慢，尤其是带大图、开了optimize的情况。可以按 CPU 核心数起进程池并行，但要注意两点：并行度别超过物理核心数（编码是 CPU 密集型，超了只会互相抢资源），以及每个进程持有一份独立的图像对象，不要跨进程共享，很容易出诡异问题。
进度反馈不是装饰。上千张图跑十几分钟，没有进度显示你就是盲等，不知道是在正常跑还是卡死了。加一个简单的计数输出（每处理 100 张打一行），或者用现成的进度条库，成本极低。日志里记得记录三个信息：当前文件、耗时、输出体积。这三项攒下来，你就能发现哪类图特别慢、哪类图压缩率异常。
失败处理的原则是单张失败不中断全局。用 try/except 包住单张的转换，捕获后把文件名和异常信息写进错误清单，继续下一张。跑完统一看清单，人工处理那几张“疑难杂症”（通常是损坏文件、格式伪装、超大尺寸、非标准编码）。这比一遇到异常就整个脚本崩掉、前面跑的两百张白跑，要靠谱得多。
提示：先在源目录里抽 10 张有代表性的图（一张照片、一张截图、一张带透明的、一张超大图、一张极小的图）单跑一遍，人眼确认结果满意，再放开全量。这一步花三分钟，能省下两小时的返工。
5. 常见问题与排查速查表
5.1 转完变糊、变色、变大了
变糊。先分清楚是哪种糊。整体发虚，通常是质量参数太低；笔画和彩色边缘出现红绿色斑或渗色，是色度子采样导致的，把 4:2:0 改成 4:4:4 多半能解决；只有局部平滑区域出现方块感，那是量化太重，把 q 提到 85 以上。还有一种“糊”是尺寸问题：源图本来就比显示尺寸小，你把它放大后再转 jpg，等于先把信息插值伪造一遍再压缩，双重损失。
变色。最常见是 ICC 丢失，尤其在广色域屏幕上会表现为整体发灰发淡。检查源图是否带 ICC，转换时显式带上。第二种是透明合成底色选错了，本该铺白的地方铺成了黑，整张图暗一圈。第三种是色彩模式没转干净，CMYK 直接当 RGB 处理，颜色会明显偏移。
变大。这个反直觉但很常见。原因通常是：源图是经过高度优化的 webp 或高质量小尺寸 png，你转成 jpg 反而没优势；或者源图是纯色、简单图形的 png（体积本来就极小），jpg 的量化表开销反而更大；又或者你用的参数过高（q95 以上），同时源图分辨率没降下来。对简单图形，正确选择是保留 png 或转 webp，别硬转 jpg。
5.2 速查表
| 现象 | 最可能的原因 | 处理办法 |
|---|---|---|
| 报错提示无法以 JPEG 保存该模式 | 图像仍是 RGBA/LA/P 模式 | 显式合成底色后转 RGB |
| 图片躺倒或镜像 | EXIF 方向标签未被应用 | 读取后先做方向矫正再编码 |
| 透明区域变成一整块黑 | alpha 被直接丢弃，默认填黑 | 手动用白色或指定色合成 |
| 彩色小字边缘出现色斑 | 4:2:0 色度子采样 | 改为 4:4:4 |
| 转完体积反而翻倍 | 源图是高效格式或简单图形 | 换参数或放弃转 jpg |
| 颜色发灰发淡 | ICC 色彩描述被剥离 | 转换时保留 ICC |
| 网页加载时先模糊后清晰 | 渐进式编码（这是特性不是问题） | 不需要改，属于预期行为 |
| 同目录出现大量重名文件 | 输出路径未做冲突检测 | 先算映射清单再执行 |
| 超大批量跑到一半内存爆掉 | 单张超大图解码占用过高 | 限制解码分辨率或分批处理 |
| 定时任务重复跑产生副本 | 缺少幂等判断 | 记录 mtime，存在即跳过 |
这张表我建议截图存着。实际排查的时候，先看“现象”那一列对上号，八成能直接定位到原因。剩下两成通常是多个问题叠加，比如既丢了 ICC 又做了一次 4:2:0，那就两处一起改。
还要强调一个不可逆的事：jpg 转回 png 不会恢复任何画质。png 是无损容器，但它只能原样保存“已经损失的像素”。很多人以为转成 png 就“无损”了，这是把容器格式和图像质量搞混了。真正的无损方案是：从一开始就保留原始源文件，所有 jpg 都当作“交付副本”，永远不要用 jpg 覆盖原图。
6. 我踩过的几个坑和实用建议
先说一个让我印象最深的。早期做一批商品图，参数统一设成 q=80、4:2:0，跑完抽看几张照片，效果很好，就上线了。结果一周后收到反馈：所有带价格标签的图，标签上的数字都模糊得看不清。原因就是标签是细笔画黑字叠在彩色背景上，4:2:0 让黑色数字的边缘吃到了背景色，q80 又把高频细节削掉了。返工时我改成按目录分流：纯实拍走 q80/4:2:0，带文字标注的走 q90/4:4:4。这个教训让我后来养成一个习惯——抽样验证时，一定要专门挑一张“最难看的图”来看，也就是信息最密集、最依赖锐利边缘的那张，而不是挑最好看的那张。
第二个坑是元数据。有一次做批量清理，为了减小体积加了去元数据的参数，结果一批从相机导出的图全部方向错乱。原因就是我去掉了 EXIF，而方向信息恰好在里面。正确顺序必须是：先按方向转正像素 → 再去元数据。顺序反过来，等于把唯一的方向线索删了再想转正，神仙也救不回来。
第三个坑跟“先缩后压”有关。有一批图原始宽度 6000 像素，但只在手机端列表里显示，宽度 750 就够。我最初偷懒没缩放，只压了质量，结果每张还有 500KB 左右。后来加了等比缩放（用高质量重采样），宽度降到 1200，再配 q82，单张直接降到 90KB 上下，而且在小屏上看反而更清楚——因为浏览器不用再对大图做一次低质量缩放。缩放和编码，两个动作要一起做，别只做一半。
第四个是关于“质量参数不是绝对”的。同一个 q 值，在不同编码器、不同色度子采样、不同优化开关的组合下，输出体积能差出三成。所以别把“q=85 就是好”当成教条，把它当成一个起点，然后用两三个样本试出你这批图的最优组合。我现在的固定流程是：抽 5 张 → 跑 3 组参数（比如 80/4:2:0、85/4:2:0、90/4:4:4）→ 对比体积和清晰度 → 选定一组 → 全量跑。这套流程走下来大概五分钟，但能避免整批返工。
最后分享一个验证小技巧。批量跑完之后，别只看体积报告，一定要做一次视觉抽检：从输出里随机抽 5 到 10 张，用看图软件放到 100% 甚至 200% 看边缘，同时对比一张原图。如果条件允许，把所有输出拼成一张缩略图总览（把每张缩小到 200×200 排成网格），一眼扫过去，哪张明显偏暗、偏色、糊掉，立刻就能发现。这个总览图法我用过很多次，比逐张打开高效得多，也比只看数字可靠得多，因为体积正常但画质翻车的图，光看报告是看不出来的。
