图片压到 100KB 还清晰？二分搜索质量参数的思路

凌晨一点，小程序后台甩给我一行红字：主包体积超限，请压缩图片资源。300 张图，每张平均 400KB，明早九点要提审。那一刻我才认真研究，压缩质量参数 q 到底是个什么东西。

核心要点

• 有损压缩的 q 不是“缩放比例”，是高频 DCT 系数的取舍阈值：q 越低，扔掉的细节越多，体积越小。
• 想压到“100KB 以内”这种目标体积，没有公式可以逆推，唯一靠谱解是对 q 做二分搜索，十几轮内必收敛。
• PNG 转 WebP 省 60% 是常态，因为 WebP 走 VP8 帧内预测 + DCT，而 PNG 死守无损，天花板被卡死。
• 在线压缩站要把图传到别人服务器，本地跑的处理器图片根本不出你的机器，这是隐私上的硬差异。

一、q 参数到底在砍什么

说人话版解释：JPEG/WebP 这类有损压缩（靠丢人眼不敏感的信息换体积），先把图切成 8x8 的像素块，做 DCT 离散余弦变换（把“这块长什么样”翻译成一串频率系数）。

低频系数描述大轮廓，高频系数描述边缘、噪点、毛发这类细节。人眼对高频不敏感，这叫视觉冗余（丢了你也看不出来），所以压缩器直接把一部分高频系数砍成零，剩下的再量化、熵编码。

q 参数控制的就是这个砍的力度：q=90 留得多，q=30 基本只剩轮廓和色块。

为什么不能一步到位算出最优 q？因为体积对 q 的响应依赖内容。天空多还是草地多，曲线完全不同。想拿“q=75 大概 100KB”的经验值硬套全目录？内容一换就翻车。

二、指定体积，为什么必须二分

需求很常见：这张图必须 ≤100KB，超了平台直接拒收。你手里只有一个旋钮 q，和一个黑盒函数 f(q) = 体积。

这函数没有解析解，但在同一张图上基本单调：q 越小体积越小。单调黑盒求目标值，标准套路就是二分搜索（每轮砍掉一半的搜索区间，逼近唯一解）：

```python

lo, hi = 1, 100

while lo < hi:

mid = (lo + hi) // 2

if compress(img, q=mid).size <= 100 * 1024:

hi = mid # 体积达标，试着提高质量

else:

lo = mid + 1 # 超了，降质量

```

log2(100) ≈ 7，七轮真实编码内必收敛。别赌运气去猜 q，猜错一次返工一次，二分是确定性收敛的。

批量压缩怎么做？对每张图独立跑一遍二分。有人问全目录共用一个 q 能不能省时间？能，但出来的体积参差不齐，指定体积的场景就别偷这个懒。

三、PNG 转 WebP 为什么能省 60%

PNG 的硬伤在于它是无损格式（一个像素都不能丢），压缩上限被熵编码卡死。它有调色板优化、有 DEFLATE，但面对照片这种每个像素都不同的内容，天花板压得很低。

WebP 有损模式直接借用了 VP8 视频编码的帧内预测：每个块先用周围已解码像素猜一个值，只编码“猜错的部分”。残差比原值小得多，再走 DCT + 量化那套流程。

实际效果：照片类 PNG 转 WebP 有损 q=75，体积降 50% 到 70% 是常态，肉眼基本无感。透明通道 WebP 也支持，原来被迫用 PNG 的图标、贴纸照样能转。

什么时候别转有损？纯色图标、截图里的文字边缘，这类“高频但重要”的内容会被压糊。改用 WebP 无损模式，通常还能比 PNG 小 20% 以上。

四、本地处理和上传处理的隐私差异

在线压缩站的工作原理：你的图 → 上传到它服务器 → 压完 → 发回来。听起来没毛病？

被坑惨过的人都知道问题在哪：合同扫描件、没发布的产品截图、客户素材，你敢往陌生服务器传吗？对面留不留副本、日志存多久，全凭良心。隐私政策写得好，不等于做得好。

本地处理器（浏览器端 WASM 或本地脚本）的差别是硬性的：没有上传这一步，就没有泄露这个攻击面。最直接的验证方式：断网，它照样能压。

批量场景差异更明显。300 张图传在线站，带宽、排队、超时全是坑。本地跑是并发的、离线的、隐私的，三个优势叠着来。

如果你手头正好有这类需求，可以直接用本站的图片压缩：全程本地跑，图片不上传服务器，指定目标体积和批量处理都支持。

FAQ / 常见问题

Q1：q=80 是不是万能安全值？

A：不是。q 的实际效果依赖图片内容和尺寸，同一个 q 在照片和截图上体积能差几倍。要控体积就老老实实二分，别背经验值。

Q2：WebP 必须有损才省体积吗？

A：不用。WebP 无损模式对标 PNG 通常也能小 20% 以上，有损只是省得更多。文字、图标类内容选无损。

Q3：反复压缩同一张图，会越来越小吗？

A：不会，只会越来越糊。有损压缩叠代是代际损失（每压一次重新量化一次，细节丢一次少一次）。压一次到位，别当免费午餐薅。