去年十一月我接了个活，帮一个做银饰的工作室整理详情页。客户发来一个 4.7G 的压缩包，解压出来 2637 张图，全是 iPhone 12 Pro 拍的，文件名从 IMG_0001 排到 IMG_2637。我点开第一张：4000×3000，4.2MB。
当时我第一反应是这得修到什么时候，第二反应才是——里面真正需要“修”的其实没几张。大部分图的问题只是太大了、比例不对、格式不对、色彩空间不对，跟好不好看一点关系都没有。
后来我想明白了。绝大多数讲图片加工的教程，一上来就跟你聊曲线、通道、液化，但普通人真正被卡住的地方都在“交付”那一步：平台说主图必须 800×800 白底，公众号说封面别超过 2MB，甲方说你这图我微信里打不开。这些全是规格问题，不是审美问题。规格搞不清，你把图修成杂志封面也没用。
一、先把参数抄下来，这比学修图软件划算多了
| 场景 | 像素尺寸 | 比例 | 文件大小 | 格式 |
|---|---|---|---|---|
| 淘宝/天猫主图 | 800×800 起，推荐 1200×1200 | 1:1 | ≤3MB，我一般压到 300KB 内 | JPEG |
| 淘宝第五张白底图 | 800×800 | 1:1 | 同上 | JPEG |
| 京东主图 | 800×800，推荐 1200×1200 | 1:1 | ≤1MB | JPEG |
| 微信公众号封面首图 | 900×383 | 2.35:1 | ≤2MB | JPEG/PNG |
| 公众号正文配图 | 宽 1080 | 任意 | ≤5MB | JPEG |
| 小红书 | 1242×1660（或 1080×1440） | 3:4 | ≤20MB | JPEG |
| 抖音全屏封面 | 1080×1920 | 9:16 | 无硬性 | JPEG |
| 朋友圈单图 | 宽 1080 | 4:3 或 1:1 | 无硬性 | JPEG |
| 闲鱼 | 1000×1000 以上 | 1:1 | 无硬性 | JPEG |
| 一寸证件照 | 295×413 | 5:7 | — | JPEG |
| 二寸证件照 | 413×579 | 5:7 | — | JPEG |
| A4 印刷（300dpi 满版） | 2480×3508 | 1:1.414 | — | TIFF/PDF |
说明几点。
一是这些数字不是死的，平台会改，而且经常改。表格里京东主图 ≤1MB 是我最后一次核对时的要求，你真要做之前最好去后台翻一眼，别信任何教程，包括这篇。
二是“推荐尺寸”和“最低要求”完全是两回事。淘宝主图最低 800×800，但你真传 800×800 上去，在详情页大图轮播里就是会比别人糊一圈。我的习惯是一律按 1200×1200 出，这样手机端双指放大还扛得住。
三是比例比尺寸重要。小红书你传 1080×1440 还是 1242×1660，观感几乎没差别，但你传个 1:1 的方图上去，它会自动给你裁成 3:4，两边的人物就被切掉了。裁图这事得自己裁，别交给平台。
二、三条路线，我劝你别一上来就开 PS
在线工具（TinyPNG、Squoosh、iLoveIMG 这类）。优点是快、零门槛、拖进去就完事。问题有三个：一，一次传几十张浏览器就开始卡，2637 张你能点到手抽筋；二，你根本不知道它背地里做了什么——我有一次图省事，拿某个在线站压了 300 张首饰图，第二天发现它默认给我加了锐化，银饰的高光全爆了，边缘一圈白边，返工干到凌晨两点；三，客户未发布的产品图传上去，等于把商业信息拱手交给别人的服务器。我现在给自己定的规矩是：客户的图，一张都不上传。
Photoshop 动作 + 批处理。适合步骤固定的活，比如“缩到 1200 + 加 4px 白边 + 轻微锐化 + 存 JPEG”。但对两千张这个量级，PS 是真的慢，而且中途随便弹一个“是否覆盖”或者“找不到字体”的对话框，你前面排队等待的时间全白费。另外 PS 从 CC 2021 之后把“存储为 Web 所用格式”挪进了“导出为”，参数逻辑变了，网上大量老教程对不上号，照着做会一脸问号。
命令行（ImageMagick / ffmpeg / Python Pillow）。学习成本大概半小时，但处理两千张时的速度和稳定性是碾压级的。那 2637 张，我写了几行命令，跑了六分多钟，中间去泡了杯茶。
ImageMagick 最常用的几条：
# 批量缩成 800×800 白底正方图
magick mogrify -path ./out -resize 800x800^ -gravity center -background white -extent 800x800 -quality 82 -strip *.jpg
# 批量转 WebP
magick mogrify -path ./webp -format webp -quality 78 -define webp:method=6 *.jpg
# 只清 EXIF，尺寸不动
magick mogrify -strip *.jpg800x800^ 那个尖号是“填充”模式，意思是缩放到能填满 800×800 为止，多出来的部分交给 -extent 裁掉。不加尖号就变成“缩放至能装进去”，出来的图会留白边。这个符号我一开始死活记不住，用错过两次。
如果要做更精细的控制，比如按主体位置裁、保留或重写元数据，就上 Pillow：
from PIL import Image, ImageOps
from pathlib import Path
src, dst = Path("in"), Path("out")
dst.mkdir(exist_ok=True)
for p in src.glob("*.jpg"):
im = Image.open(p)
im = ImageOps.exif_transpose(im) # 先把旋转信息烧进像素
im = im.convert("RGB") # 去掉 alpha 和 CMYK
im = ImageOps.fit(im, (1200, 1200), method=Image.LANCZOS, centering=(0.5, 0.5))
im.save(dst / f"{p.stem}.jpg", "JPEG", quality=82, optimize=True, subsampling=1)
ImageOps.exif_transpose 这一行是很多人会漏掉的。手机竖着拍的照片，像素其实是横的，方向信息写在 EXIF 里。你用命令行批量缩图，EXIF 被 strip 掉之后，所有竖图都会躺下来。这个坑我踩过，350 张商品图集体躺平，重做的时候我盯着屏幕愣了半分钟。
三、“DPI 到底 72 还是 300”，这问题基本在浪费时间
简单说，对屏幕而言 DPI 就是个写在文件里的数字，改它不会让图变清晰。一张 295×413 的照片，你标成 72dpi 还是 300dpi，在手机屏幕上显示出来一模一样。真正决定清晰度的只有像素数，没有别的。
唯一需要认真管 DPI 的场景是送印刷厂。这时候的换算公式是：像素数 = 物理尺寸（英寸）× DPI。A4 是 210×297mm，加 3mm 出血变成 216×303mm，换算成英寸大约是 8.5×11.9，乘 300 就得到 2551×3579 像素。印刷厂跟你说“300dpi 以上”，你直接给 2480×3508 就能过。
但有个例外我得提一句：某些电商 ERP，还有早年那版淘宝助理，会去读 EXIF 里的分辨率字段来判断你这张图“算不算高清”，你标 72dpi 它就把你打回。这不是技术原因，是写后台的人偷懒。碰上这种，你就把 DPI 元数据改成 300 糊弄过去：
magick mogrify -strip -units PixelsPerInch -density 300 *.jpg注意顺序，-strip 必须写在 -density 前面。反过来的话，你辛辛苦苦设的分辨率会被 -strip 一起清掉，等于白干。我自己是只在需要过 ERP 的那批图上保留 DPI，其余的统统 strip 干净。
四、压缩不失真，参数就那么几个
JPEG 质量我固定用 82。低于 75，人像的皮肤和渐变天空会开始出现块状和色带；高于 90，体积涨得飞快，但眼睛基本看不出区别。82 是我测了很多次之后觉得最划算的那个点。一张 1200×1200 的 JPEG，质量 82 加上 subsampling 4:2:2，大约落在 180～260KB 之间。
WebP 同画质一般还能再小 25%～35%，但它有个前提：你的下游认不认。微信公众号和淘宝主图现在还是收 JPEG 和 PNG，你传 WebP 上去它直接报错。WebP 适合的是你自己的网站、App 或者公司内网这类你能控制的地方。
PNG 只用在三种情况：透明背景、纯色块、带文字的截图。照片存 PNG 是灾难，一张 1200×1200 的照片存成 PNG 能到 3MB，而且肉眼看不出任何好处。也别把照片存成 PNG-8，会有明显色带，天空和肤色过渡的地方尤其明显。
色彩空间统一转 sRGB、8 位。相机和设计软件默认可能是 Adobe RGB 或者 ProPhoto，在本地看颜色更“厚”，但绝大多数浏览器和 App 是按 sRGB 解释的，你传上去就发灰。这事在设计圈吵了很多年，到现在还有人在踩。
还有一个顺序问题很多人搞反：锐化要在缩小之后做。缩图本身会损失锐度，你缩小之前锐化，缩完就等于白锐。正确顺序是先缩尺寸，再做一次很轻的锐化。ImageMagick 里是这样：
magick mogrify -path ./out -resize 1200x1200 -unsharp 0x0.75+0.75+0.008 -quality 82 *.jpg
那个 0x0.75+0.75+0.008 是半径 0、sigma 0.75、强度 0.75、阈值 0.008，一套用久了的网页锐化参数，够轻，不容易出白边。
五、收尾：EXIF、命名、备份
-strip 这个参数我要单独说。手机拍的照片里带着 GPS 坐标、设备型号、拍摄时间。你把这些原图发到网上、挂到二手平台，等于顺手把家庭住址报了一遍。我之前随手用工具读了一个闲鱼卖家的商品图，直接读出了他家小区的经纬度。真的别偷懒。
命名也别马虎。别用中文，别用空格，别用 # & ? 这类字符——中文名在部分平台上会变乱码，空格在命令行和 URL 里都要额外转义，& 在 URL 里会直接把参数截断。我的习惯是 sku-0001.jpg 这种，四位补零，排序不会乱：
n=1; for f in *.jpg; do mv "$f" "$(printf "sku-%04d.jpg" $n)"; n=$((n+1)); done最后一条，也是最重要的一条：改图之前先备份原图。我把它放最后写，但它是我做这行的第一条规矩。批量命令最可怕的地方在于它不会问你“确定吗”，它只会默默地把 2637 张图按你的错误参数全部覆盖一遍。我第一次用 mogrify 的时候不知道它默认是原地覆盖，等反应过来，整个文件夹的原图已经全变成 800×800 了。
从那以后我养成了一个习惯：所有批量命令，第一遍一定加 -path ./out 输出到新目录，肉眼抽查十张，确认没问题了，再考虑要不要原地处理。而且说实话，很多时候根本不需要原地处理。硬盘现在便宜得很，多留一份原图，比什么参数都强。