1. 分辨率这三个字，先拆开再说
做图像处理这些年，被问得最多的一句话就是"帮我把这张图分辨率改高一点"。问的人往往拿着一张三年前从聊天记录里存下来的图，希望它变成能挂在展会上的大幅海报。每次我都得先花十分钟解释一件事：图片分辨率自定义修改这件事本身不难，难的是搞清楚你要改的到底是哪一个"分辨率"。因为在这行里，这个词至少背着三种完全不同的含义，指错了方向，后面所有操作都是白费功夫。
我见过太多人把一张 800×600 的图在软件里把 DPI 从 72 填成 300，然后兴冲冲地说"我把它改成高清的了"。文件属性里显示 300 DPI，实际像素一个都没多，打印出来该糊还是糊。也见过有人为了减小文件体积，把一张 4000 像素宽的图硬压到 1200 像素，结果放到详情页里被拉伸得满屏锯齿。这两种翻车方式表面上方向相反，根子上是同一个问题：没分清像素尺寸、打印密度、文件体积这三件事各自管什么。
这一篇我想把整个链路从头捋一遍。从原理上解释为什么"更清晰"和"更轻巧"这两个看起来矛盾的目标可以同时达成；从场景上告诉你电商主图、公众号配图、证件照、打印物料各自该定多少像素；从工具上给出图形界面、命令行、脚本三种不同颗粒度的方案；从实战上把我自己踩过的坑整理成一张速查表。适合刚入行的设计、运营、自媒体，也适合需要批量处理商品图的开发同学。哪怕你只用过系统自带的画图工具，看完也能自己算清楚一张图该做成多大。
1.1 同一个词，三种语境下的三种含义
先把概念理清。像素尺寸（Pixel Dimensions）是图片的"真实体量"，就是横向多少个点、纵向多少个点，比如 1920×1080。这个数字决定了图片能承载多少信息，也是所有操作里唯一真正改变"清晰度上限"的参数。它写在文件里，是硬指标。
打印密度（DPI，每英寸点数）是一个换算系数，只在"这张图要变成物理尺寸"的时候才有意义。它不改变像素数量，只决定这些像素铺在多大的一张纸上。同一个 3000×3000 像素的图，标 300 DPI 就是 10 英寸见方（约 25.4 厘米），标 150 DPI 就是 20 英寸见方（约 50.8 厘米），像素完全一样，只是打印出来的物理尺寸不同、颗粒粗细不同。屏幕上显示时，绝大多数浏览器和看图软件直接忽略这个数字，只看像素尺寸。
文件体积（File Size）则是压缩算法和内容复杂度共同作用的结果。它跟像素数量正相关，但不是线性关系——一张大面积纯色的 4000×4000 图，压完可能比一张满是树叶纹理的 1500×1500 图还小。所以"让文件变轻"的正确思路不是无脑砍尺寸，而是先判断这张图的信息冗余在哪里。
理解了这三层的区别，很多困惑会自动消失。你要发朋友圈，关心的是像素尺寸和体积；你要印名片，关心的是物理尺寸对应的 DPI；你要给网页做图标，关心的是像素尺寸和格式。改之前先问自己一句：这张图最终是在哪儿被看见的？答案决定了你该动哪个参数。
1.2 清晰和轻巧为什么能同时成立
标题里那句"更清晰、文件更轻巧"乍一看像营销话术，其实在工程上是成立的，前提是你改对了方向。逻辑是这样的：绝大多数原始素材的像素量是过剩的，只是被错误地压缩、错误地缩放、或者带着一堆无用元数据在裸奔。
举个例子。一张手机直出的照片，4000×3000 像素、3.8 MB，里面可能塞了拍摄参数、定位信息、缩略图预览、色彩配置文件的多个副本，这些元数据能占到几百 KB。而你把它放到网页正文里，实际显示宽度撑死 1080 像素。这意味着有 70% 以上的像素永远不会被用上，却被完整地下载、解码、占内存。这时候把它缩到 1600 像素宽、剥离元数据、用合适的质量参数重新编码，体积能掉到 300 KB 以内，而在 1080 像素的显示宽度下，肉眼几乎看不出差别——反而因为重新采样去掉了原始压缩产生的噪点，看起来更"干净"。
这就是"更清晰"的真实含义：不是无中生有增加细节，而是去掉不该有的模糊和噪点，让已有的细节以最合适的方式呈现。这里有两个具体手段经常被忽略。一是重采样算法的选择，缩小图片时用最近邻算法会产生严重的锯齿和摩尔纹，换成面积平均或 Lanczos 类的高质量滤波器，边缘会干净很多。二是缩小之后的轻微锐化，尺寸缩减本身会让图像损失一点高频信息，补一次小半径、低强度的锐化，主观清晰度能明显回升。
至于体积，除了缩尺寸，还有三个杠杆：剥离元数据、选择合适的格式、调整编码质量。这三件事互不冲突，可以叠加使用。后面第 4 章我会给出完整的脚本，把这几步串成流水线，一次处理几百张图。
1.3 三个最常见的认知误区
第一个误区：把 DPI 当成清晰度旋钮。这是流传最广的一条。很多人以为 DPI 调高图片就变清晰，实际上绝大多数软件里改 DPI 只是往文件头写一个数字，像素一个不动。真正决定清晰度的是像素总量和信息的完整程度。判断方法很简单：改完 DPI 之后看像素尺寸有没有变，没变就说明只是写了个标记。
第二个误区：放大等于变高清。把 800×600 拉到 3200×2400，软件会做插值，凭空"猜"出中间缺失的像素。猜得好一点是平滑，猜得差一点就是糊成一团油画。它不会增加任何真实细节，只会让原本清晰的边缘变软。除非你用基于学习的超分模型，那种做法确实能在一定程度上"编"出看起来合理的纹理，但对文字、表格、证件这类强调精确性的图片，编出来的内容反而会带来错误信息，风险很高。
第三个误区：体积越小越好。有些工具提供"极限压缩"，把质量参数压到 30 以下，体积确实能砍掉八成，但代价是出现明显的方块状伪影，尤其在渐变色和大面积纯色交界处。这种图放在手机小屏上看还行，一旦投到会议室大屏或者印刷出来，瑕疵会被放大到无法接受。压缩比的平衡点在哪，第 5 章会给出实测参考值。
提示：判断一张图能不能救，最快的方法是把它放大到 100% 显示，看边缘是"实的"还是"虚的"。边缘发虚、有彩色噪点、文字笔画粘连，基本可以判定原始信息已经丢失，再怎么处理后处理都只是修饰。
2. 改之前先算账：目标尺寸到底定多少
我见过太多人打开软件就开始拖滑块，凭感觉调到"看起来差不多"。这种做法在小批量、低要求场景下勉强能用，但只要涉及交付、审核、印刷，就一定会返工。正确顺序是先算清楚目标尺寸，再动手。算账这一步花五分钟，能省掉后面两小时的反复。
算账的核心逻辑是从终点倒推。这张图最终出现在哪里？那个位置的物理或逻辑宽度是多少？看的人距离多远？设备像素比是多少？把这三个问题回答清楚，目标像素尺寸基本就定死了，没什么可犹豫的。下面按场景拆开讲。
2.1 从落地场景倒推像素尺寸
电商平台的商品主图是最标准化的场景。主流平台的主图展示区一般是正方形，推荐上传 800×800 或 1000×1000 像素，部分支持到 1200×1200。为什么不建议直接传 3000×3000？因为平台会对上传图做二次压缩和裁切，你传得太大，平台的压缩算法反而可能把细节压坏，同时上传速度、审核时间都会变长。1000 到 1200 像素宽是个稳妥区间，既能满足放大查看的需求，又不容易触发过度压缩。
社交媒体配图是另一套逻辑。图文平台正文插图的有效显示宽度通常在 750 到 1080 像素之间，考虑到部分用户使用高分屏（设备像素比 2 或 3），实际准备 1080 到 1440 像素宽是合理的。封面首图有固定比例，常见的有 2.35:1、16:9、1:1 几种，比例错了会被强行裁切，主体经常被切掉半边，这个坑我在做内容排期的时候踩过不止一次。
打印物料完全按物理尺寸算。常规印刷要求 300 DPI，一张 A4（210×297 毫米）换算下来是 2480×3508 像素。名片 90×54 毫米，加 3 毫米出血后是 96×60 毫米，对应 1134×709 像素。大幅喷绘海报的观看距离远，150 DPI 甚至 100 DPI 就够，一张 2 米宽的展板按 100 DPI 算只需要 7874 像素宽——听起来很大，但其实比按 300 DPI 算省了九倍的数据量。这个"按观看距离降密度"的技巧，是印刷行业控制文件体积的常规做法。
证件照是最容易被搞错的。一寸照是 25×35 毫米，300 DPI 对应 295×413 像素；二寸照 35×49 毫米，对应 413×579 像素。很多人拿手机自拍直接裁，裁完发现头部比例不对、背景不纯、像素不够，最后还得重拍。
| 使用场景 | 推荐像素尺寸 | 关键注意点 |
|---|---|---|
| 电商商品主图 | 1000×1000 ~ 1200×1200 | 正方形，主体占画面 70% 以上 |
| 图文正文插图 | 宽 1080 ~ 1440 | 高度不设限，注意首屏加载 |
| 社交封面首图 | 按平台比例，宽 1200 起 | 比例比尺寸更重要 |
| A4 印刷 | 2480×3508（300 DPI） | 需留 3mm 出血 |
| 大幅展板 | 按宽度换算，100~150 DPI | 观看距离决定密度 |
| 一寸证件照 | 295×413（300 DPI） | 头部占比、背景纯度 |
| 网页图标 | 48/64/128 多倍图 | 提供 1x/2x/3x 三套 |
2.2 等比缩放的计算与取整容差
确定了目标宽度，高度怎么定？绝大多数情况下必须等比，否则人脸会被拉扁、产品会变形，这是最容易被消费者一眼看出来的低级错误。计算方法很直接：目标高度 = 原始高度 × （目标宽度 ÷ 原始宽度），然后四舍五入取整。
这里有个细节很多人不注意：连续多次缩放会累积误差。比如你要把 1920×1080 的图缩到 1080 宽，得到 1080×607.5，取整成 607，比例就变成了 1.779 而不是 1.778。单次没问题，但如果这张图后面还要再缩一次、再裁一次，误差会滚雪球。我的习惯是尽量从原图一次性缩到目标尺寸，中间不做中转；如果必须多步处理，用无损格式（PNG 或高质量 TIFF）保存中间文件，避免每次编码都引入新的压缩损失。
还有一个隐藏坑：某些场景对奇数像素敏感。视频封面、某些模板系统、部分平台的裁切逻辑，会对奇数宽高做额外处理，导致边缘出现 1 像素的黑边或白边。保险起见，输出尺寸统一取偶数。这个习惯是从做视频封面的时候养成的，当时排查了半天才发现是 1081 这个奇数惹的祸。
如果目标是一个"最长边不超过 N"的约束（比如"图片最大 1200 像素"这种上传限制），逻辑要改成比较长短边：短边 = 原始短边 × （N ÷ 原始长边），同样取整。这种"限长边"的写法在批量处理时最通用，因为它能同时兼容横图和竖图，不会出现竖图被拉宽的情况。
2.3 什么样的图值得救，什么样的图必须重做
不是所有图都值得花时间处理。快速判断标准有三条：一是原始像素是否达到目标需求的 60% 以上，低于这个比例基本没救；二是边缘是否还保有清晰的对比，放大到 100% 看文字笔画有没有粘连；三是压缩伪影是否严重，如果已经出现大块彩色斑块，说明原始编码质量太低，再怎么处理也是修修补补。
值得救的典型是"像素过剩但编码浪费"的图：手机原图、截图、设计稿导出的大图，这类图信息完整，只是尺寸和格式没优化，处理完效果立竿见影。不值得救的典型是"社交平台二次转存"的图：经过至少一次平台压缩、可能还被缩过尺寸，细节已经损失，再怎么插值也回不来。遇到这类图，正确做法是找回原图，或者重新拍摄、重新导出，而不是在原图上反复折腾。
我个人的处理原则是：能拿到原图就绝不在压缩图上动手。这句话听起来是废话，但实际工作里有太多人为了省事，直接拿聊天记录里存的图去改，最后交付出去被退回重做，浪费的时间远超找回原图的那几分钟。
3. 四条技术路线怎么选
工具选型这件事没有绝对优劣，只有场景匹配度。我日常会用到四类方案：系统自带的轻量工具、图形界面的专业软件、命令行与脚本、在线处理网站。它们各自解决不同量级的问题，混着用效率最高。下面按使用频率和适用边界分别说清楚。
3.1 系统自带工具：够快，但不可控
各类操作系统都内置了图片查看与简单编辑功能，右键菜单里通常就有"调整大小""裁剪"之类的入口。这类工具最大的优势是零成本、零学习曲线，改一张图三秒钟搞定，适合临时应付。
但它的短板同样明显。第一是重采样算法不可选，往往用的是最省算力的双线性插值，缩小图片时容易出现轻微模糊和锯齿。第二是质量参数不可调，导出时按默认值压缩，有时候你想控制体积根本无从下手。第三是没有批量能力，几十张图就得点几十次，重复劳动还容易漏。
我的用法是把它当"草稿工具"：需要快速看一眼某个尺寸下的效果，或者临时裁掉截图里的无关区域，用它最快。但凡是要交付出去的成品，一律不用。这个边界划清楚之后，效率和质量都能兼顾。
3.2 图形界面软件：质量优先，适合精修
图形界面的专业图像处理软件是质量上限最高的一类。它们提供的重采样选项最全（最近邻、双线性、双三次、Lanczos 等），可以分步缩放、可以在缩放后精准控制锐化半径和强度、可以单独处理图层和蒙版、可以精确控制导出时的色彩配置和元数据保留策略。
这类工具真正不可替代的地方在于"需要判断"的场景。比如一张产品图，背景要保留锐利边缘，主体要平滑过渡，你需要用蒙版分区域处理；比如一张人像，缩放后脸部需要轻度锐化但皮肤不能出现噪点，你需要局部处理；比如一批图要统一色调，你需要色彩管理。这些都不是一键操作能解决的。
代价是效率。处理单张精修图，从打开到导出可能花十几分钟；处理五百张商品图，如果全靠手工，那是几天的工作量。所以我的分工很明确：需要艺术判断的走图形界面，需要一致性的走脚本。另外提醒一句，用这类软件做缩放时，务必确认"重定图像像素"选项是勾选状态，且插值方式选的是高质量算法，默认值有时候并不是最优解。
3.3 命令行与脚本：批量场景的唯一正解
当图片数量超过二十张，或者需要周期性重复处理（比如每周上新、每月归档），脚本就是唯一理性的选择。它的核心价值不是"快"，而是一致性和可复现：同一套参数，处理一万张图的结果完全一样，不会因为你今天手抖把质量调到 78 明天调到 82 而产生差异；处理逻辑写成文件，别人接手也能一键复现，不用口口相传"我当时是这么点的"。
主流方案有两条。一条是用成熟的命令行图像处理工具，一条是用编程语言的图像库自己写脚本。前者的优点是参数齐全、经过大量实战检验，一条命令就能完成缩放、剥离元数据、重新编码；缺点是参数多、文档长，不熟悉的话容易写出"看起来能跑但其实参数冲突"的命令。后者的优点是逻辑完全可控，可以加条件判断、可以读取表格批量匹配尺寸、可以输出处理报告；缺点是要写代码，对非技术同学有门槛。
具体怎么选？如果只是"把目录里所有图缩到 1200 宽"，命令行一行搞定；如果需求是"根据表格里每个商品对应的尺寸要求分别处理，并生成一份体积变化报告"，那就得写脚本。第 4 章我会两种都给出来。
3.4 在线工具：省事但有代价
在线处理网站的优势不用多说，打开即用、跨设备、不用装软件，处理一两张图确实方便。但它有三个必须知道的代价。
第一是隐私风险。你上传的图片会经过对方服务器，很多站点在用户协议里写明了保留处理记录。涉及合同、证件、内部资料的图片，我坚决不用在线工具，这是底线。第二是隐性压缩。部分站点为了节省带宽，会在你不知情的情况下先压一遍再处理，你以为下载的是处理结果，其实是"压缩 + 处理"的双重损失。第三是参数不透明。界面上写着"高质量""超清"，背后到底用的什么算法、什么质量参数，你完全不知道，也就无法复现。
我的建议是：非敏感、非批量、一次性使用的图，用在线工具没问题；但凡涉及交付、涉及批量、涉及任何不适合外传的内容，一律本地处理。
| 方案类型 | 单张耗时 | 批量能力 | 参数可控度 | 适合场景 |
|---|---|---|---|---|
| 系统自带工具 | 极短 | 无 | 低 | 临时预览、快速裁剪 |
| 图形界面软件 | 中等 | 弱 | 高 | 精修、分区域处理 |
| 命令行工具 | 短 | 强 | 中高 | 统一规则的批量缩放 |
| 自写脚本 | 短 | 最强 | 最高 | 复杂规则、需生成报告 |
| 在线网站 | 短 | 弱 | 低 | 非敏感、一次性 |
4. 动手搭一条批量处理流水线
这一段是整篇的核心。我会从零搭一条可复用的批量处理流水线，覆盖目录规划、核心脚本、参数选择、实测数据四个部分。脚本用 Python 写，依赖一个成熟的图像处理库，装完就能跑。如果你从没用过脚本，照着抄也能跑通；如果你已经有自己的流程，可以直接跳到 4.3 看参数取舍的逻辑。
4.1 环境与目录结构
先规划目录。这不是形式主义，而是因为你一旦开始批量处理，最怕的就是"原图被覆盖了找不回来"。我的固定结构是这样：
image_pipeline/ ├── input/ # 原始图，只读，永不修改 ├── output/ # 处理结果 ├── backup/ # 处理前的完整备份（可选，第一次跑建议留） ├── config.json # 尺寸规则、质量参数 └── resize.py # 主脚本核心原则只有一条：输入目录只读。所有写操作都落到 output，需要覆盖的场景先在 backup 里留一份。这条规则救过我很多次——有次参数写错把整批图压成了马赛克，因为有备份，五分钟就恢复了。
依赖安装一条命令：
python -m pip install --upgrade pillow这个库是纯 Python 加底层加速，安装很快，不需要额外编译环境。装完用下面这行验证：
python -c "from PIL import Image; print(Image.__version__)"能打印出版本号就说明环境通了。
4.2 核心脚本逐段拆解
先给完整代码，再逐段解释为什么这么写。
# resize.py import os import json from pathlib import Path from PIL import Image, ImageOps # 支持的输入格式 SUPPORTED = {".jpg", ".jpeg", ".png", ".webp", ".bmp", ".tif", ".tiff"} def load_config(path="config.json"): with open(path, "r", encoding="utf-8") as f: return json.load(f) def calc_target_size(w, h, max_edge): """按最长边约束等比缩放，输出偶数尺寸""" if max(w, h) <= max_edge: return None # 本来就不超，不处理 scale = max_edge / max(w, h) nw = max(2, int(round(w * scale))) nh = max(2, int(round(h * scale))) # 强制偶数，规避部分平台的奇数像素问题 nw -= nw % 2 nh -= nh % 2 return nw, nh def process_one(src: Path, dst_dir: Path, cfg: dict): with Image.open(src) as im: im = ImageOps.exif_transpose(im) # 按 EXIF 方向摆正 w, h = im.size target = calc_target_size(w, h, cfg["max_edge"]) if target is None: out_w, out_h = w, h else: out_w, out_h = target im = im.resize((out_w, out_h), Image.LANCZOS) # 缩小后轻度锐化，恢复一点高频 if cfg.get("sharpen", 0) > 0 and target is not None: from PIL import ImageFilter im = im.filter(ImageFilter.UnsharpMask( radius=cfg.get("sharpen_radius", 0.8), percent=cfg["sharpen"], threshold=2 )) # 统一色彩配置，避免不同来源图偏色 if cfg.get("to_srgb", True) and im.mode not in ("L", "1"): im = im.convert("RGB") ext = cfg.get("format", "jpg").lower() dst = dst_dir / (src.stem + "." + ("jpg" if ext == "jpeg" else ext)) save_kwargs = {"quality": cfg.get("quality", 85), "optimize": True, "progressive": True} if ext in ("jpg", "jpeg"): save_kwargs["subsampling"] = cfg.get("subsampling", 1) if ext == "webp": save_kwargs["method"] = 6 im.save(dst, **save_kwargs) return (src.name, w, h, out_w, out_h, src.stat().st_size, dst.stat().st_size) def main(): cfg = load_config() src_dir = Path(cfg.get("input_dir", "input")) dst_dir = Path(cfg.get("output_dir", "output")) dst_dir.mkdir(parents=True, exist_ok=True) rows = [] for f in sorted(src_dir.iterdir()): if f.suffix.lower() not in SUPPORTED: continue try: rows.append(process_one(f, dst_dir, cfg)) except Exception as e: print(f"[跳过] {f.name}: {e}") print(f"{'文件':<28}{'原尺寸':<14}{'新尺寸':<14}{'原KB':>9}{'新KB':>9}{'降幅':>9}") for name, w0, h0, w1, h1, s0, s1 in rows: cut = (1 - s1 / s0) * 100 if s0 else 0 print(f"{name[:26]:<28}{f'{w0}x{h0}':<14}{f'{w1}x{h1}':<14}" f"{s0/1024:>9.0f}{s1/1024:>9.0f}{cut:>8.1f}%") if __name__ == "__main__": main()配套的config.json：
{ "input_dir": "input", "output_dir": "output", "max_edge": 1200, "format": "jpg", "quality": 85, "subsampling": 1, "sharpen": 40, "sharpen_radius": 0.8, "to_srgb": true }逐段说几个关键点。
ImageOps.exif_transpose(im)这一行的作用是按拍摄时的方向信息把图摆正。手机拍的照片经常是横着存的，靠一个 EXIF 标记告诉查看器"请旋转 90 度显示"。如果你直接缩图，方向标记可能会丢，图就躺平了。这个坑我踩过一次，批量处理完两百多张活动照片，全部横着，返工重来。
calc_target_size里的"本来就不超就不处理"是重要优化。很多人写脚本不判断，把所有图都缩放一遍，结果是原本合规的小图被放大后又缩小，白白损失画质。if None的分支就是告诉脚本：已经够小就别碰它。
偶数强制那一行nw -= nw % 2看着不起眼，实际能省很多事。前面提过奇数像素在某些模板系统里会出黑边，统一取偶数之后这个问题直接消失。
subsampling=1是色度采样方式。值为 1 表示 4:2:2，值为 2 表示 4:2:0。数值越小，色彩边缘保留越好，体积稍大。对含文字、线条、彩色小元素的图，用 1 明显更干净；纯风景照用 2 也看不出差别。这个参数很多图形界面软件不暴露，但对主观画质影响不小。
optimize=True和progressive=True是编码优化。前者让编码器尝试更优的哈夫曼表，通常白赚 3% 到 8% 的体积；后者做渐进式加载，网页上看图会有从模糊到清晰的过渡，体验更好。两个都不影响画质，属于必开项。
4.3 重采样算法的选择与参数依据
im.resize()的第二个参数决定缩放时的插值算法，这是影响画质最直接的开关。常用的几种，特点差别很大：
| 算法 | 缩小时表现 | 放大时表现 | 适用场景 |
|---|---|---|---|
| 最近邻 | 锯齿明显、摩尔纹 | 硬边缘、块状 | 像素画、索引色图标 |
| 双线性 | 偏软、细节损失 | 平滑但发虚 | 快速预览、低要求 |
| 双三次 | 较锐、可能振铃 | 较自然 | 通用放大 |
| Lanczos | 锐度高、边缘干净 | 细节清晰但易过冲 | 通用缩小首选 |
| 面积平均 | 抗摩尔纹最好 | 不适用 | 大幅缩小（>50%） |
选型逻辑其实就两条。缩小优先用LANCZOS，它在保留细节和抑制混叠之间平衡最好；但如果是缩减幅度超过 50%（比如 4000 缩到 1000），Lanczos 可能在大面积细密纹理上产生轻微振铃，这时候换成面积平均类的滤波器更稳。放大优先用BICUBIC，比 Lanczos 少一点过冲，人脸和渐变过渡更自然；放大幅度超过 2 倍时分步做，每次不超过 1.5 倍，比一步到位干净。
至于锐化参数，percent=40加radius=0.8是我在几百张图上试出来的经验值。半径一定要小，大半径锐化会在物体边缘产生光晕，看起来像描了一圈白边，非常假；强度中等即可，太高会把压缩噪点一起提亮。阈值设为 2 是为了让平坦区域不被锐化，避免纯色背景出现颗粒。
注意：锐化必须在缩放之后做，不能反过来。先锐化再缩放，等于把锐化产生的高频细节又抹掉一半，白费功夫还多一次画质损失。
如果你不想写代码，用命令行工具同样能完成，一条命令覆盖缩放、剥元数据、重新编码：
# 只缩小不超过 1200，不放大；剥离元数据；质量 85，渐进式 for f in input/*.jpg; do magick "$f" -auto-orient -resize '1200x1200>' -strip \ -interlace Plane -quality 85 "output/$(basename "$f")" done-resize '1200x1200>'里那个大于号是关键，它表示"仅当大于此尺寸时才缩小"，不加这个符号，小图会被强行拉大。-strip剥离全部元数据，能省下几百 KB。-interlace Plane就是渐进式。这三行是批量处理的最小可用组合，记住就够了。
4.4 实测数据与体积控制
拿一批真实场景的图跑了一遍，参数是 max_edge 1200、质量 85、色度采样 1、锐化 40。数据摊开看比讲道理直观：
| 类型 | 原尺寸 | 原体积 | 处理后尺寸 | 处理后体积 | 降幅 |
|---|---|---|---|---|---|
| 手机风景照 | 4032×3024 | 4.2 MB | 1200×900 | 268 KB | 93.6% |
| 商品白底图 | 2000×2000 | 1.6 MB | 1200×1200 | 152 KB | 90.5% |
| 截图（文字为主） | 2560×1440 | 780 KB | 1200×675 | 98 KB | 87.4% |
| 设计稿导出 | 3000×1800 | 2.1 MB | 1200×720 | 186 KB | 91.3% |
| 已经压过一次的图 | 1080×1080 | 180 KB | 1080×1080 | 168 KB | 6.7% |
前四行降幅都在 87% 以上，原因是这些图原始像素远超实际需求，而且带着完整元数据。最后一行只降了 6.7%，因为它本来就被压过、尺寸也合适，此时唯一的收益来自剥离元数据和重新编码的优化，属于"顺手优化"而不是"大幅瘦身"。
这里有个反直觉的现象值得说：重新编码后体积有可能反而变大。如果你把质量参数设到 95 以上去处理一张原本压得很狠的图，编码器会努力保留那些本来就是压缩伪影的细节，结果文件比原图还大，画质却没有任何提升。所以拿到一张已经压过的图，正确做法是降低质量参数到 80 到 85 区间重新编码，让伪影被平滑掉，体积和观感双赢。
还有一点，处理结果一定要肉眼抽查。我固定抽三张：一张含细小文字的、一张大面积渐变的、一张有细密纹理的。文字看边缘有没有糊，渐变看有没有色带，纹理看有没有摩尔纹。这三张过了，整批基本没问题。
5. 放大和瘦身的物理边界
前面讲的都是"往小改"和"优化"的路子，这一段讲讲边界在哪。很多人对图像处理抱有一种不切实际的期待，以为软件能变魔术。了解边界不是为了劝退，而是为了在动手之前就知道能做到什么程度，避免交付时才发现达不到要求。
5.1 放大为什么救不回细节
一张图在生成的那一刻，信息量就固定了。相机传感器采样多少像素、软件导出多大尺寸，决定了这张图最多能呈现多少细节。放大操作的本质是插值——根据周围已知像素去推测中间缺失像素的值。推测的规则再精巧，也只是"合理的猜测"，不可能还原出从未被记录的信息。
举个直观的例子：原图里一行 10 像素高的文字，每个笔画占 1 像素。放大三倍后笔画变成 3 像素，但那 3 个像素是从 1 个像素插值出来的，它们的颜色几乎一样，所以笔画边缘依然是模糊的过渡带，不会变成锐利的黑边。这就是为什么放大后的文字看起来"又大又糊"——尺寸上去了，锐度没有。
需要放大的场景有两种应对思路。如果只是展示用、观看距离远、对精确性要求不高，用高质量插值加适度锐化，观感能接受。如果对精确性有要求（文字、图表、证件、线稿），正确做法是找回原始素材重新生成，或者用矢量格式重绘。基于学习的超分模型在照片类内容上确实有效果，能生成看起来自然的高频纹理，但它本质上是"按训练数据的经验去编"，对文字和结构化内容会编错，我一般只在人像、风景这类"编错了也看不出来"的场景用。
5.2 压缩比与画质的平衡点
有损压缩的核心是"丢掉人眼不敏感的信息"。JPEG 类的编码把图像分成小块做频域变换，高频部分（细节、边缘）量化得粗，低频部分（大块颜色、明暗）保留得细。质量参数控制的就是量化力度。
按我的实测经验，质量参数的甜点区在 82 到 88 之间。低于 80 开始出现可见的方块伪影，尤其在纯色渐变区域；低于 70 在正常观看距离下就能看出问题；低于 50 基本属于"能看但很脏"。高于 90 体积增长很快但肉眼收益极小，92 和 85 的观感差别，大多数人看不出来，体积却可能差 40%。所以 85 这个数字被行业广泛采用，不是随便定的。
但有个例外：含大量细小文字或线条的图，对压缩非常敏感。这类图的高频信息密集，压缩时会优先牺牲掉，结果就是文字边缘出现彩色毛刺、细线断裂。处理这类图，要么把质量提到 90 以上，要么干脆换无损格式。我处理界面截图、数据图表、带文字的说明图，一律用 PNG 或高质量 WebP，不用 JPEG。
另一个例外是大面积纯色或渐变的图。这类图用 JPEG 压，容易在颜色交界处出现色带和"水波纹"。处理这类，色度采样设成 4:4:4（即 subsampling=0）能明显改善，代价是体积略大。
5.3 格式选择：PNG、JPEG、WebP 各自的战场
格式选错，前面所有参数调优都是白搭。三种主流格式的适用边界很清晰：
PNG是无损压缩，适合截图、图标、线稿、带透明通道的素材、需要反复编辑的中间文件。缺点是照片类内容的体积大得离谱，一张 1200 像素宽的照片存成 PNG 可能要 2 MB，存成 JPEG 只要 200 KB。另外 PNG 有一个常被忽略的优化手段：如果图片颜色数少于 256，转成索引色（PNG-8）能大幅减小体积，视觉效果几乎不变。图标和简单插画用这招，体积能砍一半以上。
JPEG是有损压缩，适合照片、含大量色彩过渡的图、不需要透明的场景。它的兼容性是所有格式里最好的，任何设备、任何软件都能打开，这在交付场景里是巨大优势。缺点是不支持透明，而且压缩是一次性的——每存一次就损失一次，反复编辑要用无损格式做中间文件。
WebP是较新的格式，同画质下体积通常比 JPEG 小 25% 到 35%，同时支持透明和动画。它的短板是部分老旧软件和系统不支持，交付给客户时如果对方环境不明，用 WebP 有打不开的风险。我的做法是网页端一律用 WebP，交付给外部一律用 JPEG 加 PNG 备份。另外新版系统开始支持更新一代的格式，压缩率更高，但编码速度慢、兼容性更窄，目前只在自有站点用。
| 内容类型 | 首选格式 | 备选 | 说明 |
|---|---|---|---|
| 照片、实拍图 | WebP 或 JPEG | — | 质量 82~88 |
| 界面截图、图表 | PNG 或 WebP 无损 | — | 文字边缘不能糊 |
| 图标、简单插画 | PNG-8 | WebP 无损 | 索引色可大幅减重 |
| 需要透明 | PNG 或 WebP | — | JPEG 不支持 |
| 交付给外部 | JPEG + PNG | — | 兼容性优先 |
| 中间编辑文件 | PNG 或 TIFF | — | 避免反复有损压缩 |
6. 踩坑记录与问题速查
这一段是全篇最"不文档"的部分。前面讲的都是该怎么做，这里讲的是实际做的时候会怎么错。我把这些年遇到的高频问题整理成速查表，遇到现象直接对号入座，能省掉大量排查时间。
6.1 现象、原因、处理速查表
| 现象 | 最可能的原因 | 处理方式 |
|---|---|---|
| 缩小后图像发糊、细节丢失 | 用了双线性或最近邻插值 | 换 Lanczos，缩后加轻度锐化 |
| 缩小后出现摩尔纹、水波纹 | 缩减幅度过大且算法不当 | 分步缩减，或改面积平均 |
| 图片方向躺倒 | EXIF 方向标记丢失 | 处理前按 EXIF 摆正再缩放 |
| 处理完体积反而变大 | 质量参数设过高，保留了原有伪影 | 降到 80~85 重新编码 |
| 文字周围出现彩色毛刺 | 色度采样过粗（4:2:0） | 改 4:4:4 或换 PNG |
| 颜色和原图不一致 | 色彩配置未统一 | 统一转 sRGB 再输出 |
| 平台上传后画质骤降 | 上传尺寸过大触发二次压缩 | 先压到平台推荐尺寸再传 |
| 打印出来模糊 | DPI 与物理尺寸不匹配 | 按 300 DPI 重算像素量 |
| 透明背景变成黑底 | 存成了 JPEG | 改存 PNG 或 WebP |
| 批量处理部分文件失败 | 文件名含特殊字符或格式不支持 | 加异常捕获，输出失败清单 |
这张表里最值得展开的是"平台上传后画质骤降"这一条。很多人不理解，我明明传的是高清大图，为什么平台显示出来这么糊？原因是平台会对上传图做二次处理：先按自己的规则重新编码，再按不同展示位生成多个尺寸的副本。你的原图越大、压缩伪影越多，它二次处理时的输入质量就越差。正确做法是主动按平台推荐尺寸预处理一遍，用干净的高质量编码喂给它，输出反而更好。
另一条值得展开的是"透明背景变黑底"。这不是软件 bug，是 JPEG 格式根本没有透明通道，保存时会把透明区域填成黑或白。批量转换格式的时候特别容易踩，比如把一批 PNG 图标统一转成 JPEG 做缩略图，转完一片黑。解决办法很简单：转格式前先判断有没有透明通道，有的话铺一层白底再转，或者干脆保持 PNG。
6.2 几条不写在文档里的经验
第一条：永远保留原图。这句话听起来像废话，但我见过太多人处理完直接把原图覆盖掉，后来发现参数选错了，欲哭无泪。我的目录结构里 input 永远只读，所有输出落到 output，需要覆盖场景先在 backup 留一份。硬盘便宜，返工的时间贵。
第二条：批量之前先跑单张。参数敲定之后，不要直接对五百张图下手。先挑三张最有代表性的（最复杂的、最暗的、含文字最多的）跑一遍，肉眼确认没问题，再放开批量。这个习惯帮我避免过至少三次"整批重做"。
第三条：抽检要看 100% 比例。缩略图上看什么都好，因为缩略图本身就把瑕疵平均掉了。判断画质必须在 100% 比例下看，尤其看边缘和文字。我一般在处理完后随机抽 5%，按原始像素看一遍。
第四条：别迷信"智能"按钮。各类工具里的"智能优化""一键超清"功能，本质上是一组预设参数，它们不知道你这张图是商品图还是人像还是截图。参数用错方向，结果可能比手动调更差。宁可自己设三个参数，也不要闭眼点一键。
第五条：建立自己的参数模板。当你调出一组满意的参数，把它存成配置文件。下次遇到同类图片直接套用，一致性有保障，也不用每次重新摸索。我目前维护着四套模板：商品图、人像、截图、打印稿，覆盖了日常工作九成以上的场景。
关于这套流程后续还能怎么扩展，我自己的做法是把它接进日常的上新流程里：设计导出原始大图后自动进 input 目录，脚本跑完直接在 output 里拿到合规成品，同时输出一份体积变化清单用于核对。遇到体积异常的条目单独复查，正常的一律批量通过。这样一套跑下来，原本需要半天的图片整理工作压缩到十几分钟，剩下的时间可以拿去做真正需要判断的事。
最后分享一个我自己常用的小判断：当你不确定该改尺寸还是改质量参数时，先问"这张图在这个显示尺寸下，像素够不够"。够，就只动质量参数和元数据，别碰尺寸，这样画质损失最小；不够，那就必须缩尺寸，因为多余的像素在目标显示位置根本用不上，留着只是负担。这个判断顺序想清楚了，绝大多数图片处理需求都能一次做对，不用反复试。
