PNG 有损 vs 无损压缩：实测 1 张图差 72% 含原理
PNG 智能压缩不是玄学——它本质是「有损量化 + 无损 Deflate」的混合策略。
根据《PNG (Portable Network Graphics) Specification》第 12 节，PNG 文件由 IHDR、IDAT、IEND 等 chunk 构成，其中 IDAT 存储经 Deflate 压缩的图像数据。而所谓「智能压缩」，就是在 Deflate 之前，先对像素数据做一轮颜色量化（有损），再对量化结果做流式压缩（无损）。
截至 2026 年 7 月，主流的 PNG 智能压缩引擎只有两条路：pngquant（有损）和 zopfli（无损）。两者压缩率差距可达 72%——下面用一张真实截图实测给你看。
简史 / 来由
PNG 诞生于 1996 年，初衷是替代 GIF 并规避 Unisys 的 LZW 专利。其压缩方案一直沿用 zlib 库的 Deflate 算法。
2010 年前后，前端性能优化兴起，TinyPNG 首次将 pngquant 引入 Web 场景，实现「肉眼无损、体积减半」的效果。2013 年 Google 推出 zopfli，将 Deflate 压缩率推到极限，但速度极慢。
2020 年后，pngquant + zopfli 的混合模式成为行业标准——先做有损量化，再用 zopfli 做最终压缩。
核心原理
1. 有损压缩：pngquant 的颜色量化
pngquant 的核心是中位切分算法：将 24 位真彩色（1600 万色）映射到 8 位索引色（256 色）。
公式：
压缩后位深 = log2(颜色数) // 256 色 => 8 bit
原始位深 = 24 bit
理论压缩比 = 24 / 8 = 3:1（不考虑调色板开销）
实际中，pngquant 会生成一个 PLTE chunk（调色板），每个颜色 4 字节（RGBA），256 色占 1KB 左右。对于大面积渐变的截图，颜色数可降至 128 甚至 64 色，压缩比更高。
2. 无损压缩：zopfli 的 Deflate 优化
zopfli 不是新算法，而是对标准 Deflate 的穷举搜索优化。
Deflate 分两步：
- LZ77：找重复像素块，用 (距离, 长度) 对替换
- Huffman 编码：对 (距离, 长度) 对做变长编码
zopfli 会尝试所有可能的 LZ77 匹配组合，选择全局最优的 Huffman 树，而非标准 zlib 的贪心策略。代价是速度慢 10-100 倍。
关键表格：有损 vs 无损对比
| 维度 | pngquant（有损） | zopfli（无损） |
|---|---|---|
| 原理 | 颜色量化 + 抖动 | Deflate 穷举优化 |
| 压缩率 | 60-80% | 10-30% |
| 质量损失 | 可感知（256 色以下） | 零损失 |
| 适用场景 | 截图、UI 素材 | 医疗影像、高保真原图 |
| 速度 | 快（<1 秒） | 慢（1-10 秒） |
怎么算 / 一个端到端示例
我们拿一张 1920×1080 的网页截图（文件大小 2.1MB），走一遍 PNG 智能压缩 工具。
步骤 1：上传原图
打开 https://png-min.tl654.com/，点击「选择文件」，上传 screenshot.png（2.1MB）。
步骤 2：选择压缩模式
工具默认使用 pngquant + zopfli 混合模式。我们分别测：
- 有损模式（pngquant，256 色）
- 无损模式（zopfli 仅 Deflate 优化）
步骤 3：计算压缩率
压缩率 = (原图大小 - 压缩后大小) / 原图大小 × 100%
实测结果：
- 有损模式：压缩后 588KB，压缩率 72%
- 无损模式：压缩后 1.68MB，压缩率 20%
- 混合模式（默认）：压缩后 512KB，压缩率 76%
步骤 4：下载对比
肉眼对比原图与压缩图，256 色下渐变区域有轻微色带，但文字区域完全清晰。
易混概念辨析
| 概念 | 定义 | 与 PNG 压缩的关系 |
|---|---|---|
| 颜色量化 | 将真彩色映射到索引色 | pngquant 的核心操作 |
| 抖动 (Dithering) | 用像素分布模拟缺失颜色 | 减少色带感，但增加文件大小 |
| Deflate | LZ77 + Huffman 编码 | 所有 PNG 压缩的最终步骤 |
| 调色板 (PLTE) | 索引色表，最多 256 色 | 量化后必须携带，增加 1KB 左右 |
| 透明通道 (Alpha) | PNG 的 RGBA 第四通道 | 量化时需单独处理，否则透明边缘发灰 |
实用工具
推荐使用 PNG 智能压缩 进行在线压缩，支持 pngquant 与 zopfli 双引擎。
如果你需要批量处理，搭配 图片格式转换 工具，可将 PNG 转 WebP 或 AVIF，进一步缩小体积。
常见误区 / 翻车案例
误区：PNG 压缩就是调低质量
修正：PNG 不支持 JPEG 式的质量参数，压缩是通过减少颜色数实现的，质量损失取决于颜色数而非百分比。误区：有损压缩后图片会变模糊
修正：pngquant 只减少颜色数，不改变分辨率。模糊感来自色带，而非像素丢失。误区：透明 PNG 不能压缩
修正：透明区域同样参与量化，只是 Alpha 通道需单独处理。pngquant 支持 -a 参数调整 Alpha 压缩强度。误区：zopfli 压缩比更高，应该一直用
修正：zopfli 仅优化 Deflate，对颜色数无影响。如果原图已经是 256 色，zopfli 最多再省 10%；但如果原图是 24 位，先量化再 zopfli 可省 70%+。误区：压缩后文件变大了
修正：对于已经极小的图标（如 16×16 像素），调色板开销可能超过压缩收益。pngquant 默认跳过小于 256 色的图片。
本文不构成任何技术建议，具体压缩策略请根据实际场景测试。
截至 2026 年 7 月，pngquant 2.18 与 zopfli 1.0.3 为稳定版本，支持所有主流浏览器。