图片压缩原理：有损压缩与无损压缩区别

先聊点我在业务里踩过的压缩坑

做端侧性能优化快6年，前前后后经手过的图片压缩需求没有一百也有八十，踩过的坑能列半页文档：
- 刚入行的时候为了压OSS存储成本，把全站商品图统一转成质量60的JPG，结果上线第二天就被运营打爆电话——手表的金属拉丝纹理全糊成了塑料感，衣服上的刺绣图案边缘全是色块，转化率直接掉了1.2个点；
- 后来吸取“教训”，所有上传的图一律存无损PNG，结果存储成本当月超了预算35%，移动端首屏图片加载耗时涨了400ms，用户跳失率涨了快8个点；
- 再后来跟风切WebP，没做参数对标，直接把质量参数设成和JPG一样的80，结果压出来的图体积比JPG还大，折腾了两周上线，收益微乎其微，被性能组的同事笑了半个月。

很多新手对图片压缩的认知特别极端：要么觉得有损压缩就是“糊”，是偷工减料；要么觉得无损压缩就是“良心”，不惜成本也要上。实际上压了几十万张图之后我才明白，有损和无损本质上是两种完全不同的信息精简思路，没有绝对的好坏，只有场景合不合适。

核心原理差异：到底“丢了什么”“留了什么”

两种压缩模式的底层逻辑从根上就不一样，理解了这个就不会出现选型的方向性错误。

无损压缩：从编码层面挤掉“水分”

很多人以为无损压缩是“什么都不改变小体积”，其实本质上它根本不会改动图片的任何一个像素值，只是换了一种更高效的信息存储方式。
举个最直白的例子：一张白底黑字的截图，连续上千个像素都是纯白色，按原始位图存储的话，每个像素都要单独记录RGB值，光这一片白色就要占几千字节；无损压缩的算法会直接标记“从X坐标到Y坐标的区域全是白色”，用一个很短的标记代替重复的像素信息，解码的时候再完整还原回来，和原图逐像素对比都不会有任何差异。
实际工程里常用的无损压缩手段无非这几种：行程编码、霍夫曼编码、DEFLATE算法（就是PNG用的）、字典编码。它的压缩比天花板完全取决于图片本身的信息重复度：如果是纯色多、线条规整的Logo、UI切图、文字截图，无损压缩能把体积压到原图的10%甚至更低；但如果是细节丰富的实景照片，比如满屏的树叶、噪点、细碎纹理，没有多少重复信息可以挖，无损压缩最多也就压到原体积的60%左右，再怎么调参数都挤不出水分了。

注意很多网上推荐的PNG压缩工具比如PNGquant，本质是通过减少颜色数量来压体积，属于有损压缩，别把它当纯无损工具用，压文字截图很容易出现色带。

有损压缩：从人眼感知层面做“取舍”

和无损压缩死磕编码效率不一样，有损压缩的核心逻辑是：既然图片最终是给人看的，那人眼看不到、分辨不出的信息，就没必要留着。
它不是瞎删信息，所有的丢信息逻辑都是盯着人眼的视觉缺陷设计的：
- 人眼对亮度变化的敏感度，是对色彩变化敏感度的4倍左右，那就把色彩通道的分辨率降一半，绝大多数人根本察觉不到；
- 人眼对画面里的高频细节（比如距离远的细碎纹理、高ISO带来的随机噪点、非常锐利的边缘跳变）分辨力很弱，那就通过离散余弦变换（JPEG的核心算法）、帧内预测（WebP/AVIF的核心算法）把这部分信息量化滤掉；
- 相邻像素之间如果色彩差异很小，人眼分辨不出，就合并成相近的颜色值，减少需要存储的颜色数量。

很多人对有损压缩的印象是“压完就有马赛克”，这其实是参数设太狠突破了感知阈值——亲测只要参数卡在感知临界点上，普通用户根本分不出和原图的区别，但是体积能直接压到原图的10%-30%，收益是无损压缩比不了的。

工程视角下的核心参数对比

我整理了平时做选型最关心的几个维度，都是实际在生产环境跑过的数据，没有实验室理想值：

对比维度	有损压缩	无损压缩
常规压缩比	实景图1:5~1:10，极限可到1:20（画质崩坏）	实景图1:1.5~1:3，纯色UI图可达1:10以上
画质特性	不可逆的感知损失，阈值内无肉眼可辨差异	0损失，解码后与原图逐像素一致
透明通道支持	传统JPG不支持，WebP/AVIF/JXL有损支持	PNG/WebP无损/AVIF无损均支持
编解码速度	JPG编码极快，WebP中等，AVIF较慢	PNG编解码中等，WebP无损解码快、编码略慢
反复转码影响	每转码一次叠加一次画质损失	任意次转码无画质损失
典型适用场景	实景照片、Banner图、用户上传的生活照	Logo、UI切图、文字截图、需要二次编辑的设计稿
常见生产格式	JPEG、WebP（有损）、AVIF（有损）、JXL（有损）	PNG、WebP（无损）、AVIF（无损）

我压了几十万张图总结的落地选型规则

说一千道一万，原理最终要落到线上能用的规则上，这几条是我在不同业务线（电商、内容社区、工具类App）反复验证过的，照着做基本不会出大问题。

先看图片内容，再选压缩模式

别上来就纠结用什么格式、设什么参数，先看图片本身是什么类型：
- 如果是带细线条、小字号文字的内容：比如规则截图、参数说明图、几何形状的Logo、App里的功能图标，直接选无损模式。我之前踩过坑，把12号字的规则截图压成质量75的JPG，结果文字边缘全是蚊噪，用户投诉说“字糊得像近视没戴眼镜”，后来换回无损WebP，体积比之前的JPG还小30%，边缘完全清晰。
- 如果是实景类内容：比如商品实拍图、用户发的生活照、风景Banner、美食探店图，直接选有损模式。这类图本身就有很多人眼不敏感的细节和噪点，上无损纯纯浪费带宽，只要参数设得合适，根本没人能看出区别。
- 如果是需要透明通道的元素：比如弹窗的半透明遮罩、不规则形状的贴纸，别直接上PNG，优先选带透明支持的有损WebP/AVIF，同清晰度下体积能比PNG小60%以上。

质量参数别瞎抄网上的通用值

我见过太多人直接抄“JPG质量设80”的经验贴，上线之后要么体积压不下来，要么画质糊。这里给一组我亲测在移动端视觉效果最均衡的参数，注意不同格式的质量参数没有线性对应关系，不能直接照搬数值：
- JPEG：质量设75-80，关闭逐行扫描（低端机解码快），是体积和画质的甜点区，超过85之后体积涨得飞快，画质提升微乎其微；
- WebP有损：质量设65-75，开智能色度子采样（smartSubsample），观感和JPG 85基本一致，体积小30%左右；
- AVIF有损：质量设45-55，开自适应块划分，观感和JPG 80基本一致，体积比WebP还小25%左右。

踩过的血坑：绝对不要对有损压缩过的图做二次转码！每做一次有损编码，就会叠加一次量化损失，哪怕每次都用最高质量参数，来回转个三四次，画质也会明显劣化。做图床或者图片服务的话，一定要留存原始无损图，所有尺寸、格式的压缩版本都从原图生成，别拿已经压过的图反复转。

几个零成本的压缩优化技巧

这几个技巧我在好几个业务线用过，基本不需要改架构，就能白嫖15%-30%的体积收益：
1. 所有无损PNG上线前，过一遍zopflipng或者optipng优化，在完全不损失画质的前提下，还能再挤掉20%-40%的冗余头信息、无效数据。之前我把全站几百张UI切图过了一遍zopflipng，静态资源包体积直接降了1.7M，啥副作用都没有。
2. 有损压缩一定要开自适应量化，不要全局用固定质量参数。现在主流的图片处理库（sharp、libvips）、云厂商的图片服务都支持这个能力：画面里平滑的区域（比如天空、墙面）就压得狠一点，细节丰富的边缘（比如文字、商品轮廓）就自动提质量，实际跑下来比固定质量参数多省20%体积，边缘画质还更好。
3. 低端机别硬上AVIF。之前我们在低端机占比30%的业务线全量AVIF，结果低端机上解码单张图平均耗时280ms，比JPG慢4倍，图片加载的白屏时间明显变长，后来改成根据设备性能兜底：中高端机用AVIF，中端机用WebP，低端机用JPG，整体体积收益没降多少，加载耗时反而降了15%。

平时我在Node.js服务里用sharp做压缩的基础配置放下面，参数都是调过的，基本可以直接抄：

const sharp = require('sharp');

// 实景图 有损WebP压缩配置 亲测移动端观感最优
async function compressPhoto(inputPath, outputPath) {
  await sharp(inputPath)
    .resize({ width: 1080, withoutEnlargement: true }) // 先缩放到移动端最大显示宽度 避免传原图
    .webp({
      quality: 70,
      smartSubsample: true, // 智能保边缘清晰度 避免文字/轮廓发虚
      effort: 4, // 平衡编码速度和压缩率 数值越高压得越慢
      alphaQuality: 80 // 透明通道质量 不透明图不影响
    })
    .toFile(outputPath);
}

// UI/截图 无损WebP压缩配置
async function compressAsset(inputPath, outputPath) {
  await sharp(inputPath)
    .webp({
      lossless: true,
      effort: 6,
      nearLossless: false
    })
    .toFile(outputPath);
}

那些年我见过的压缩认知误区

最后说几个新手特别容易信的错误认知，我之前也被这些说法坑过：
1. 误区一：无损压缩一定比有损压缩清晰
这个说法只有在你逐像素对比、放大到100%抠细节的时候才成立。实际移动端浏览场景下，图片是缩放到屏幕宽度看的，当有损压缩的参数卡在感知阈值以上时，普通人盲测根本分不出哪个是有损哪个是无损。我之前做过一次内部测试，同一张服装实拍图，压成70质量的WebP（168KB）和原无损PNG（1.8MB），找了20个产品、运营、开发来区分，正确率只有52%，和抛硬币瞎猜差不多。这时候硬上无损，就是为了用户根本感知不到的信息，花10倍的存储和带宽成本，完全没必要。
2. 误区二：压缩率越高的算法越好
图片压缩永远是「体积-画质-编解码性能」的三角平衡，没有绝对最优的算法。比如AVIF压缩率确实比WebP高30%，但是编码耗时是WebP的2倍，低端机解码慢好几倍，如果你的用户里低端机占比高，硬上AVIF反而会让图片加载更慢，体验更差。选压缩算法的时候别光看压缩率，一定要结合自己的用户设备分布、编解码资源成本综合算。
3. 误区三：把文件后缀改成PNG就是无损了
我见过太多运营同学把已经压得满是块效应的JPG，直接改个后缀名成.png就往后台传，觉得这下就是无损高清了，实际上除了文件体积涨了两三倍，画质半毛钱变化都没有，纯纯无效操作。
4. 误区四：GIF是有损的动图格式
GIF本身用的LZW编码是纯无损的，画质差是因为它最多只支持256种颜色，把真彩色动图转成256索引色的过程中丢了颜色信息，不是压缩算法本身的问题。现在做动图优先用WebP动图或者AVIF动图，同画质下体积比GIF小60%以上，还支持真彩色，比GIF香太多。