3. 资源格式选型

图片压缩，说白了就是在「画质」和「体积」之间找平衡。我见过太多团队，要么死磕无损导致包体积爆炸，要么压得太狠图片糊成马赛克。这一章，咱们把压缩这件事彻底聊透。

有损压缩 vs 无损压缩：核心差异

先看一张对比表，你心里就有数了：

维度	有损压缩	无损压缩
原理	丢弃人眼不敏感的色彩/细节信息	优化数据存储方式，不丢失任何像素
还原度	不可逆，画质有损失	完全还原，与原图一致
压缩率	通常 50%~90%	通常 10%~40%
典型格式	JPEG、WebP（有损模式）、AVIF	PNG、GIF、WebP（无损模式）
适用场景	照片、渐变图、背景大图	图标、截图、UI 界面、需要透明通道的图

我个人习惯这样选：照片用有损，界面元素用无损。但这不是绝对的——你想想看，一张 1920×1080 的 Banner 图，如果硬要用 PNG，那体积能飙到 5MB 以上，用户加载时直接崩溃。

压缩工具实战：三款主流工具怎么选？

工具不在多，顺手就行。我这些年用过不下十款压缩工具，最后常驻工作流的就这三个：

TinyPNG — 在线压缩的标杆

TinyPNG 用的是「量化+降色」技术。它会分析图片中相近的颜色，把它们合并成更少的色值，然后重新编码。效果很稳，我几乎每天都会用到。

• 优点：操作极简，拖拽上传即可；支持 PNG/JPEG/WebP；压缩率通常在 60%~80%
• 缺点：单次最多 20 张，每张不超过 5MB；需要联网
• 我的用法：设计稿切图后，批量拖进去压一遍，再丢进项目

ImageOptim — 本地无损压缩利器

ImageOptim 是 macOS 上的免费工具，主打无损压缩。它背后集成了 PNGCrush、OptiPNG、JPEGOptim 等多个引擎，一键运行就能把图片里的元数据、注释、无用色块全部清理掉。

• 优点：完全本地运行，不传图到服务器；支持批量处理；无损压缩效果明显
• 缺点：仅 macOS；压缩速度偏慢（尤其大图）
• 我的用法：处理 PNG 图标和 Sprite 图时必用，能压掉 30%~50% 的体积

Squoosh — Google 出品的全能选手

Squoosh 是我最近用得最多的工具。它既可以在线用，也能通过 CLI 集成到构建流程。最吸引我的是它的「实时对比」功能——左边原图，右边压缩后，你可以滑动对比，肉眼确认画质可接受。

• 优点：支持 JPEG/PNG/WebP/AVIF 互转；可调节压缩参数；开源可自部署
• 缺点：WebP 编码器在某些场景下不如 cwebp 稳定
• 我的用法：做 WebP 和 AVIF 转换时首选，参数调起来非常直观

压缩策略：什么时候压？压到什么程度？

光有工具不够，还得有策略。我曾经在一个项目中吃过亏——设计师给了一套 4K 分辨率的 Banner 图，我直接丢进 TinyPNG 压了一遍就上线了。结果移动端加载时，图片还是 2MB 多，首屏白屏了 3 秒。后来我才意识到：压缩不是一次性的，要分阶段、分场景。

我总结了一套「三阶段压缩策略」：

1. 设计阶段压缩：设计师导出时，就选择合理的格式和品质。比如 JPEG 品质选 80~85，肉眼几乎看不出区别，体积能小一半。
2. 构建阶段压缩：在 Webpack/Vite 构建流程中，用 imagemin 插件自动压缩所有图片资源。这一步可以批量处理，而且能保证所有图片都被压过。
3. 运行时按需压缩：对于用户上传的图片，用 Squoosh CLI 或 Sharp 库在服务端实时压缩，再返回给前端。

知识体系：压缩决策流程

下面这张图，是我在实际项目中梳理出来的压缩决策流程。每次拿到一张图，按这个流程走一遍，基本不会出错：

避坑指南：我踩过的三个坑

做图片压缩这些年，我踩过不少坑。分享三个印象最深的：

• 坑一：过度压缩导致画质崩坏。 我曾经为了追求极致体积，把 JPEG 品质压到 30。结果上线后，用户反馈图片全是色块和噪点。后来我定了个规矩：品质不低于 60，且必须经过设计师确认。
• 坑二：PNG 转 WebP 时忽略透明通道。 有一次我把一个带透明背景的 Logo 转成 WebP，结果透明部分变成了黑色背景。排查了半天才发现，WebP 编码器默认不保留 Alpha 通道，需要显式指定 -alpha_q 100 参数。
• 坑三：压缩工具选错导致元数据丢失。 用 ImageOptim 处理摄影作品时，默认删除了 EXIF 信息，导致摄影师找不到拍摄参数。后来我养成了习惯：处理前先检查工具设置，该保留的元数据一定要保留。