PNG 智能压缩

底层算法相同：先用 pngquant 把 PNG 转成 256 色以内的索引色，再用 zopfli 做最慢但压缩率最高的 Deflate 编码。实测同一张 24 位 PNG 下，本工具压缩率与 TinyPNG 偏差通常在 1-3% 以内，视觉差异肉眼不可见。区别在于 TinyPNG 是上传到远程服务器处理，本工具直接在浏览器里跑 WASM，不上传任何文件。

pngquant 默认用 256 色（8 位索引色），如果原图是摄影类渐变丰富的 PNG，颜色数压缩后可能出现色斑或细节丢失。本工具没有暴露 pngquant 的 --quality 参数（如 60-80），所以无法在界面上调节质量。如果需要保留更高颜色精度，建议用支持有损压缩参数的桌面工具（如 ImageAlpha）或直接输出 24 位 PNG。

受浏览器内存限制。WASM 版的 pngquant + zopfli 需要把整张图片解码到内存里处理，对于 4000×4000 像素以上的大图，或原文件超过 20 MB 的 PNG，手机上可能直接崩溃，PC 上也可能卡死。建议在 2000×2000 以内、文件 5 MB 以下的 PNG 使用体验最佳。超大图请用桌面端工具或分块处理。

如果原图已经是用 pngquant 或 TinyPNG 压缩过的 8 位 PNG，再次压缩时 pngquant 会尝试重新索引颜色，但 zopfli 对已经高度压缩的数据再压缩收益极小，甚至因为重编码开销导致文件变大。另外，如果原图是 24 位但颜色极少的纯色图（如只有 10 种颜色的 UI 图标），pngquant 降色到 256 色不会减少体积，zopfli 的额外处理反而增加。

不会。所有处理代码（pngquant + zopfli 的 WASM 版本）都在浏览器本地运行，图片数据从始至终不离开本机。可以断网测试：加载页面后断开网络，仍然可以正常压缩。隐私敏感场景（如设计稿、证件照、合同截图）可以放心使用。

pngquant 降色时会把相近颜色合并到一个色表中。如果原图包含大量接近白色但略有差异的像素（如 #FFFFFF 和 #FEFEFE），合并后可能整体偏灰。另外，pngquant 默认使用「中值切割」算法，对某些渐变区域的颜色映射不够精确。解决方法：如果颜色精度要求高，可以考虑在 Photoshop 里先转成 8 位索引色并手动优化色表，再用本工具做最后的 zopfli 无损压缩。

主要耗时在 zopfli 阶段。pngquant 降色通常 0.5-2 秒，zopfli 对同一张图会尝试几千种压缩策略，耗时是普通 PNG 压缩的 50-100 倍。一张 1000×1000 的 PNG 在 PC 上约需 5-15 秒，手机浏览器可能 30-60 秒。如果觉得太慢，可以缩小图片尺寸再压缩，或者改用只做 pngquant 的工具（如 pngquant 官网的在线版）。

本工具界面只支持单文件上传。如果需要批量处理，可以考虑：1）用 pngquant 命令行工具（brew install pngquant）配合 find 命令批量处理；2）用 TinyPNG 的 API（付费，有每月免费额度）；3）如果文件数量少（≤10 个），可以逐个上传，本工具不限制压缩次数。

可以，但颜色信息已经损失。pngquant 把 24 位真彩色降为 8 位索引色后，原图的渐变色细节不可恢复。如果后续需要在 Photoshop 里调色或添加图层，建议保留一份未压缩的原图。如果只是用于网页展示或微信发送，压缩后的版本足够，且再次压缩不会进一步变小（颜色数已经固定）。