图片处理批量压缩不模糊：我拿 6000 张图测了 ImageMagick、libvips、Sharp 和在线 AI，最后留下这套流程

先说结论，可能跟你想的不一样：图片处理里最贵的不是压缩算法，也不是 AI 模型，而是“上传、下载、人工返工、色彩不一致”这四件事。我去年帮一个做家居类目的朋友处理 6000 张商品图，原图 18.7GB，平均 3.1MB，尺寸从 800×800 到 6000×4000 都有。测试机器是联想小新 Pro 14，Ryzen 7 5800H、16GB 内存、Windows 11 + WSL2 Ubuntu 22.04。我把 ImageMagick 7.1.1-15、libvips 8.14.5、sharp 0.32.5 和两个在线 AI 工具都跑了一遍，最后留下的不是“最先进”的方案，而是“最像工厂流水线”的方案。

一、先别急着压，90% 的模糊是尺寸和色彩空间搞出来的

很多人搜“图片处理怎么不模糊”，第一反应是调 JPEG 质量。其实我踩过的坑里，真正导致糊的通常是三件事：原图被反复另存、色彩空间从 Adobe RGB 转到 sRGB 时没做转换、以及先压到 800px 再放到 1200px。特别是第三点，很多人用在线工具先压一遍，发现不够清晰又拿回来放大，像素已经被扔了，AI 也救不回细节。

我的做法是先把原图归档，保留 RAW、PSD 或 PNG 母版，命名成 SKU_原图_20250217，不直接覆盖。然后批量预处理只做四步：自动旋转、转 sRGB、按目标尺寸裁切、去元数据。ImageMagick 命令是这样：

magick mogrify -path out -auto-orient -colorspace sRGB -resize 1200x1200^ -gravity center -extent 1200x1200 -strip -interlace Plane -quality 82 *.jpg

注意 -resize 1200x1200^ 里的 ^ 是先填满再裁切，不是直接拉伸。-strip 会去掉 EXIF、GPS 和缩略图，能省 5% 到 15% 体积。但如果你做的是摄影网站，别乱 strip，版权信息可能就在 EXIF 里。

二、ImageMagick、libvips、sharp 实测：差 4 倍，不是玄学

同一批 6000 张图，输出 1200×1200、JPEG q82、渐进式、sRGB。ImageMagick 单线程跑完 18 分 42 秒，CPU 基本吃满一个核。libvips 8.14.5 跑完 4 分 12 秒，内存峰值 380MB 左右。sharp 0.32.5 跑完 3 分 57 秒，但 Node 进程内存峰值到了 620MB，因为并发开到了 8。如果把 sharp 并发降到 4，时间变成 5 分 20 秒，内存降到 410MB。所以不是 sharp 一定最快，而是它吃并发。

libvips 的命令更短：

vips thumbnail in.jpg out.jpg 1200 --height 1200 --crop centre --Q 82

它默认就是流式处理，适合大图。6000×4000 的图，ImageMagick 单张要 1.2 秒，libvips 只要 0.28 秒。但 libvips 的坑是文档少，参数名跟 ImageMagick 不通用，比如 --crop centre 不是 -gravity center。我第一次跑的时候没加 --crop，结果输出了一堆 1200×800 的图，详情页全乱套。

sharp 我一般写成 Node 脚本，核心参数：

sharp(input)
  .rotate()
  .resize(1200, 1200, { fit: 'cover', position: 'centre' })
  .toColorspace('srgb')
  .jpeg({ quality: 82, progressive: true, mozjpeg: true })
  .toFile(output);

mozjpeg: true 比默认 JPEG 编码器小 8% 到 12%，但编码时间多 20% 左右。对 6000 张图来说，多等 1 分钟，换每张少 30KB，我觉得值。

三、在线 AI 和本地 CLI 的对比：AI 适合救火，不适合当流水线

我也试了两个在线 AI 图片处理工具，一个主打无损放大，一个主打智能压缩。单张效果确实有惊喜：一张 800×800 的沙发图，AI 放大到 1600×1600 后，木纹边缘比传统 Lanczos 干净。但问题也很明显：6000 张图，按 0.05 元/张算，一次 300 元；按 20MB/张上传，18.7GB 在 100Mbps 上传带宽下要 25 分钟，实际加上排队、下载、重试，我花了 2 小时 17 分。而且不同批次结果有轻微差异，颜色偏暖 2% 到 4%，详情页和主图放一起能看出来。

更麻烦的是隐私。家具图里有客户家的实拍，上传到第三方 API，合同里没写数据保留多久，我朋友直接否了。后来我们改成：90% 标准图走本地 CLI，AI 只处理三类非标件——老图修复、要去背景的透明材质、需要放大到 200% 以上的主图。这样 AI 调用量从 6000 张降到 240 张，成本从 300 元降到 12 元，时间也从 2 小时降到 18 分钟。

我的观点可能有点反潮流：别把 AI 当图片处理的底座，把它当“插件”。流水线要的是确定性、可复现、能回滚。AI 给的是概率性结果，适合处理例外，不适合每天跑 6000 张。

四、压缩参数别抄一个数：JPEG、WebP、AVIF 我建议这么分

很多人问“图片处理压缩到多少才不模糊”。我实测下来，1200×1200 电商主图，JPEG q82 的 SSIM 是 0.981，q70 是 0.956，q60 是 0.923。q60 在手机上看还行，但放大看面料纹理已经发糊。所以我的默认值是：主图 JPEG q82，列表图 q78，详情页长图 q80。WebP 用 q78，AVIF 用 q32，但 AVIF 编码速度比 JPEG 慢 6 到 10 倍，6000 张图用 avifenc 0.11.1 跑了 42 分钟，最后我只给首屏 20 张用了 AVIF，其余还是 WebP + JPEG 兜底。

还有两个参数容易被忽略：渐进式 JPEG 和色彩配置文件。-interlace Plane 让图片从上到下逐渐清晰，弱网体验好一点。转 sRGB 后，要么嵌一个 sRGB IEC61966-2.1，要么彻底去掉 ICC，别一半嵌一半不嵌。我见过同一个详情页里，有的图偏红，有的图偏绿，就是 ICC 没统一。

质检我不用肉眼一张张看，用 ImageMagick 的 compare：

magick compare -metric SSIM original.jpg processed.jpg diff.png

SSIM 低于 0.95 的自动进“人工复检”文件夹。6000 张里只有 37 张低于 0.95，主要是深色背景和细条纹衣服。这个比例大概是 0.6%，人工看得过来。

五、我最后留下的流程，你可以直接抄

第一步，原图归档，不动母版。第二步，用 libvips 或 sharp 批量转 sRGB、裁 1200×1200、去元数据、输出 JPEG q82。第三步，用 cwebp 转一份 WebP q78，首屏 20 张再转 AVIF q32。第四步，用 magick compare 跑 SSIM，低于 0.95 的抽检。第五步，上传 CDN，前端用 srcset 做响应式：

<img src='sku-123-1200.jpg' srcset='sku-123-640.jpg 640w, sku-123-1200.jpg 1200w' sizes='(max-width: 640px) 640px, 1200px' width='1200' height='1200' alt='北欧布艺沙发'>

整套跑下来，18.7GB 原图变成 1.9GB 输出，体积降了 89.8%，视觉上在 1200px 下和原图差距很小。耗时方面，libvips 预处理 4 分 12 秒，WebP 转换 6 分 30 秒，SSIM 质检 2 分 08 秒，总共不到 15 分钟。如果全走在线 AI，成本至少 300 元，时间 2 小时起，还要担心隐私和色彩偏差。

最后说一句不太讨喜的话：图片处理没有“一键神器”。你要的如果是每天几千张、可复现、能追责，就用本地 CLI 流水线。你要的是单张惊艳、老图复活、去背景，就用 AI。把两者混在一起，才是现在大部分团队翻车的根源。