批量图片压缩，别再死磕Photoshop了，命令行工具才是效率神器

上个月要处理一批电商产品图，总共一万两千多张RAW转出来的TIFF，每张大概25MB，需要转成WebP挂到网站上去。我一开始用Photoshop做动作批处理，跑了一个晚上，到第二天早上发现才处理了不到八百张，而且电脑风扇跟直升机似的。后来实在忍不了，在脚本编辑器里试了试libvips，结果整个跑完花了不到20分钟。这个反差让我觉得很荒诞——我们一直默认PS这种图形化工具就是专业的代名词，但面对重复性的、大体量的图片转换任务，它可能恰恰是最差的选择。

为什么差？首先是内存管理。PS每打开一张25MB的TIFF，内存占用能飙到1个GB以上，因为它在后台保留了大量历史记录、调整图层和缓存。而libvips这类流式处理库，按行读取数据，处理一万张大图的内存峰值能锁在300MB以内。我用的是Mac Studio 64GB内存，跑PS动作时其他工作根本没法进行，换成libvips的vipsthumbnail命令并行调四个进程，CPU利用接近百分百，但我还能正常浏览网页和聊微信。

压缩率不是唯一的指标，色彩和元数据才是大头

很多人对比图片处理工具喜欢拿压缩率说事，比如同一张图Sharp压缩到80KB，TinyPNG压到85KB，然后就说Sharp更好。但真正处理过大量图片就会明白，压缩率差异百分之五以内根本不影响用户体验，甚至肉眼难以分辨。更关键的是色彩空间的保留和元数据。我之前用squoosh的WebP压缩，发现它默认会把EXIF里的色彩配置文件给剥离掉，导致大量图片颜色发灰。后来去翻squoosh的GitHub issue，发现这是老毛病，他们的sharp版本在保存时如果不指定iccEmbed，同样的坑也会出现。

更重要的是元数据的去留。很多设计师不关心版权信息和拍摄参数，但做图片库卖图的人就知道，一旦元数据丢了，图就值不了钱了。我自己的处理流程里，第一道工序永远是剥离不必要的元数据（比如GPS、设备序列号），只保留通过白名单的字段，这一步用exiftool做，一次搞定十万张。然后再进入压缩环节，最后用AppleScript验证成品的色彩配置。这个顺序不能反过来——先压再清元数据会导致压缩算法读入无效的ICC profile，产生奇怪的色偏。

各个工具的真实差异：Sharp、libvips、TinyPNG、cwebp

我自己用不同工具处理同一组512张图片做了个简单的基准测试。图片是尼康Z7拍摄的RAW转TIFF，尺寸8256x5504，转换成质量80的WebP。结果libvips用时47秒，单核内存占用约150MB；Sharp用时1分12秒，内存峰值约500MB（因为用了libvips的底层但封装不一样）；cwebp自带命令用时1分48秒，内存倒是很稳，只有80MB；TinyPNG网页版传了三个小时还没好，最后放弃了，而且它有每张最大尺寸限制，超过4000像素还得先缩小。

这里说个反直觉的点：Sharp在某些场景下比libvips原生命令慢，但在处理多页TIFF或者需要逐像素操作时反而更方便。比如Sharp可以很方便地给图片加圆角蒙版和文字水印，而用libvips命令行做同样的事得写一大串Vips操作符，调试起来头疼。我的做法是：批量转换走libvips，个性化定制用Sharp脚本，各吃各的饭。

我踩过的那些坑和解决步骤

如果你也想用命令行批量压缩图片，我以前踩过的坑也许能帮你绕开。第一步，别直接用Homebrew安装libvips，然后跑到官网看教程，因为官网推荐的vipsthumbnail只生成缩略图，它不会自动旋转方向，手机拍的竖图会横躺。解决办法是加--rotate参数，或者在调用前用exiftran -ai预处理。第二步，颜色问题，转换WebP时一定要指定--endianness? 不对，那是TIFF的事。正确做法是给vips copy加--icc-transform。第三步，并行处理别开太多进程，我试过同时开8个libvips进程，结果硬盘i/o成了瓶颈，速度反而降到单进程的三分之一，后来控制在4个进程，刚好打满SSD的读写极限。

最后想说的是，工具选择本质上是一种哲学选择。Photoshop和GUI工具适合需要逐张观看、调整的精细工作，它们让用户感到一切尽在掌控。但批量图片处理恰恰是反人性的——不需要注视每一张图，需要的是稳定的算法、可重复的参数和让机器去跑的耐心。我不再迷信某个软件，而是把处理流程拆成：清洗元数据 -> 转换格式 -> 压缩质量 -> 验证色彩，每一环用最趁手的开源工具。这样处理完一万张图，杯子里泡的茶还剩下半杯热的。