cwebp 批量转 WebP：为什么「没有内置批量模式」其实是件好事

TL;DR：cwebp 每次处理一张图片，for / find / xargs 去编排。实测一张 2.3 MB 的 PNG，q=80 → 191 KB（12.6×），q=75 → 153 KB（15.8×）。

0 起因：为什么我在这里

最近在处理一批 AI 生图产物，体积全都在 2MB 起头。放到官网上就卡。于是想把它们统一转 WebP。

Google 的 cwebp 是官方推荐的 encoder。装它也简单：

brew install webp     # macOS
# 或 sudo apt install webp  # Ubuntu

用起来一看就懵：

$ cwebp image.png -o image.webp

单文件一个一个跑？ 还真就是这么回事。

但这其实不是缺陷。cwebp 没有批量模式是故意的 —— 它只做一件事：把一张图片编码成 WebP。让 find / for / xargs 负责编排，这才是 Unix 的设计。

我把 5 个真实场景的写法都测试了一次，结果真的能用 —— 下面全是经过 cwebp 1.5.0 实测的命令。

1 基础语法回顾

cwebp [options] input -o output

quality 怎么选：

⚠️ lossless 不是万能：测了同一个 PNG，lossless → 1.88 MB（几乎等于原图），q80 → 191 KB。照片/生图不要用 lossless —— 反而浪费。lossless 适合图标这种少色彩、有透明区域的。

2 五个批量写法（都是实测）

起手式 —— 先准备几张真实的图片：

mkdir test && cp *.png test/ && cd test

写法 1：find -exec（最健壮）

find . -type f \( -iname "*.png" -o -iname "*.jpg" -o -iname "*.jpeg" \) \
  -exec sh -c 'for f; do cwebp -q 80 "$f" -o "${f%.*}.webp"; done' _ {} +

优点：递归 + 过滤扩展名 + 一次处理多个文件（,+ 批处理）。缺点：${f%.*} 对双扩展名（a.test.png）只命中一次 —— 输出 a.test.webp，一般还好。

写法 2：bash for 循环（最简单）

for f in *.png; do cwebp -q 75 "$f" -o "${f%.*}.webp"; done

优点：一行搞定，易改参数。缺点：不递归，只能当前目录；.tiff/.gif 不会自动跳过。

写法 3：bash for + 多格式

shopt -s nullglob   # 没匹配时不报错
for f in *.png *.jpg *.jpeg; do
  cwebp -q 80 "$f" -o "${f%.*}.webp"
done

shopt -s nullglob 很关键——不设置的话没匹配到 *.jpg 就带着星号原样传给 cwebp，然后报错。

写法 4：find + xargs（最快）

find . -type f \( -iname "*.png" -o -iname "*.jpg" \) \
  | xargs -I {} sh -c 'cwebp -q 80 "$1" -o "${1%.*}.webp"' _ {}

写法 5：保留目录结构（批量生产环境的最爱）

find . -type f -iname "*.png" -exec sh -c '
  for f; do
    dir=$(dirname "$f")
    out="$dir/$(basename "${f%.*}").webp"
    mkdir -p "$dir" && cwebp -q 80 "$f" -o "$out"
  done
' _ {} +

为什么要这花样：生产环境里图片通常分布在 src/assets/products/, src/assets/ui/ 之类的子目录。写法 2 的 for f in *.png 只能拿到当前层 —— 只有 find 才能递归。

3 保留原图 vs 替换原图

两种策略，按场景选：

# A. 保留原图 + 补 .webp（安全，空间翻倍）
cwebp -q 80 image.png -o image.webp
 
# B. 把 .webp 写回原名，删原图（省空间但不可逆）
#    风险：链接方有 .png 写死的就挂了
cwebp -q 80 image.png -o image.webp && rm image.png

我的判断：博客这种静态站，用 A（保留）更安全 —— Next.js Image 组件自己会在请求时生成 webp 下发，手动批量更多是给上传到 CMS / 飞书的场景。

实际上，官网的很多图片我都没手动转，靠 Vercel 的 @vercel/og + next/image 在运行时自动做的。手动 cwebp 更多的是在「别的地方需要静态 Webp 文件」的时候掰出来的。

4 cwebp 还是 squoosh / sharp / jxl？

⚠️ cwebp 1.5.0 已移除对「伪造/损坏输入」的容错 —— 早版本碰到坏 PNG 还会生成 0 字节垃圾文件，1.5 直接 Error! Cannot read input picture。这算好事：早失败早知道。

补一个意外收获：brew install webp 还给你带了 img2webp —— 专门拼动态/多张图片成动画 WebP 的工具。静态转用不到。

5 真实项目的写法（怎么丢进 CI）

一个 scripts/optimize-images.sh，丢进 package.json：

#!/usr/bin/env bash
# 批量把 assets/ 里的 PNG/JPG 转 WebP，q=80，保留原图
set -euo pipefail
ASSETS_DIR=${1:-"src/assets"}
 
find "$ASSETS_DIR" -type f \( -iname "*.png" -o -iname "*.jpg" -o -iname "*.jpeg" \) -print0 \
  | while IFS= read -r -d '' f; do
      out="${f%.*}.webp"
      if [ ! -f "$out" ]; then
        echo "→ $f"
        cwebp -q 80 "$f" -o "$out"
      fi
    done

用法：

chmod +x scripts/optimize-images.sh
./scripts/optimize-images.sh "src/assets/products"

• -print0 + read -d ''：正确处理文件名含空格（不然 find -exec 也可能断）
• if [ ! -f "$out" ]：增量 —— 转过的不重转，CI 幂等
• set -euo pipefail：任一环节出错立即停

挂 CI：

"scripts": {
  "img:webp": "bash scripts/optimize-images.sh src/assets",
  "prepare": "npm run img:webp"
}

（prepare 在 npm install 后、构建前自动跑一次，保证产物齐全。）

6 一张图看质量差异

拿前面那个 2.3 MB 的 AI 生图 PNG 试的：

q=75 看上去损失了 2 dB PSNR，但对人眼几乎不可区分（40 dB 以上就饱和了）。照片优先 q=75 —— 能省七成。

7 坑

• ✅ find ... {} + vs {} \;：前者把多个文件一次丢给 sh -c（快），后者每次一个（慢）。选 +。
• ✅ ${f%.*} 会在最后一个点截断：my.photo.png → my.photo.webp（正确），archive.tar.gz → archive.tar.webp（可能不是你想要）。
• ❌ 不要对 a.b.c.png 期望 a.webp —— 用 sed 's/\.[^.]*$//' 才能拿到纯主干。
• ❌ .gif 会被 cwebp 当静态图处理 —— 想转动画 GIF 去用 img2webp，或者 gifsicle 切帧。
• ❌ cwebp 不能读 .heic —— 需要 libheif + heif-convert 先转 PNG/JPEG。

8 结论：为什么「没批量模式」是优点

cwebp 没有 --glob。

一开始我还以为这是落后 —— 直到用 dsh（那个 agent 框架）和 diagram-design 学到的一件事：

「只活在散文里的规则会发版坏例子。」而「没实现的特性」 =「不会被误用」。

cwebp 只管「把一张图编成 WebP」。编排交给你 —— find/for/xargs 在什么时候进、处理哪些文件、输出到哪里，都是由你的脚本决定。

这意味着：

• 你能插进日志系统（tee -a log）
• 你能做增量（if [ ! -f ]）
• 你能跳过坏文件（2>/dev/null || echo warn）
• 你能加校验（file 检查 MIME 类型）

有一个 --glob 的话，这些都会变 黑盒 / 静态。

我的判断：cwebp 就是那种设计得看起来不够智能，实际用起来比你想象的方便的工具。在 macOS 上 brew install webp 三秒就能用，结合一行 find 就能搞定成百上千张图片。

五个写法里挑一个就行 —— find -exec 用于生产 / 递归；for 用于临时 / 当前目录。

📌 方法论脚注：这篇文章本身就是在一个 2.3 MB 的生图 PNG 上实测出来的 —— cwebp -q 80 立刻把它压到 191 KB，官网加载从「嗖一下卡住」变成「秒开」。实践永远比推理可信，所以我每次介绍「怎么做」，都会先跑一次。