这感觉像个 bug：把 PNG 丢进压缩工具，出来的"压缩版"竟然比原文件*更大*。这不是 bug——这是无损格式的工作方式，而且它恰恰指出了真正的解决路径。
为什么会变大
PNG 本来就是压缩过的。 每个 PNG 内部都经过 deflate 压缩，不存在"未压缩的 PNG"可供瘦身。当工具对它重新编码时，有三种情况会让结果膨胀：
- 原图已被充分优化。 如果源文件出自一个精心选择过滤器和调色板的导出工具，用默认参数做一次通用重编码，产物反而*更低效*。
- 调色板丢失。 很多小 PNG 是 8 位（256 色调色板）格式。处理管线把它解码到 32 位 RGBA 画布再保存，输出就成了真彩色——体积可能翻几倍，画面却毫无差别。
- 内容本来就不适合 PNG。 用 PNG 存照片天生巨大；无损重编码最多削掉几个百分点，有时还会适得其反。
按图片类型对症下药
- 是照片？直接放弃 PNG。 转成质量 75–85 的 JPEG 或 WebP。"PNG 怎么压不动"的问题通常到这里就结束了：5 MB 的 PNG 照片变成 300 KB 的 WebP，肉眼看不出差别。带"自动"模式的工具会替你做这个判断，把非 JPEG 输入转向 WebP。
- 是带透明的截图 / UI 图？用 WebP（无损或高质量有损），保留 Alpha 通道，体积通常直接减半。
- 是必须保持 PNG 的图标？ 那真正的优化手段是*调色板量化*（压到精心挑选的 ≤256 色），需要专门的 PNG 优化器——通用重编码无能为力。不做量化的工具，就无法有意义地压缩一个本已优良的 PNG。
经验法则
当"压缩 PNG"这一步收效甚微甚至倒退时，是格式在告诉你：这个容器装错了内容。别跟编码器较劲——换格式。决策树很短：照片 → JPEG/WebP；需要透明 → WebP；死磕 PNG → 调色板量化，或接受现有体积。
无论走哪条分支，都要逐文件对比前后体积——诚实的工具会把两个数字都摆出来，让"越压越大"永远不会悄悄混进生产环境。