如何减小 AVIF 文件体积，同时保持格式不变
AVIF 本来就是一种高效的图片格式，但这不代表每个 AVIF 文件都已经压到位。设计工具和导出脚本往往采用偏保守的质量设置，于是首屏大图或商品图库即使已经是 AVIF，仍可能比实际需要更重。
真正的问题不是 AVIF 能不能再次压缩——当然可以。问题是如何减小 AVIF 文件体积，同时避免误改尺寸、转换成其他格式，或直到上线以后才发现画质受损。
先把尺寸调整到用户真正看到的大小
压缩不能让多余像素变得有用。如果页面里图片最多只显示为 1200 像素宽，而源文件有 4000 像素宽，那么先调整尺寸，通常比再跑一次编码器更有效。
检查布局中的最大显示尺寸，同时考虑高像素密度屏幕，然后按实际需求附近的尺寸导出。原图应保存在交付目录之外，以便将来重新处理；Web 用图是衍生版本，不应该替代存档原件。
保留较大源文件也有合理场景。响应式图片可能需要多个宽度，而可缩放的商品查看器需要比普通卡片更多的细节。重点是主动做决定，不要因为主文件最顺手，就让每个访客下载它。
压缩 AVIF，但不要转换格式
尺寸合适后，选择一个输出仍为 AVIF 的压缩工具。这听起来理所当然，但有些工具所谓的“压缩 AVIF”只是接受 AVIF 输入，最后却悄悄导出 WebP 或 JPG。
PiPic 的规则更简单：AVIF 进去，优化后的 AVIF 出来，宽高保持不变。免费 AVIF 压缩工具既可以处理单个文件，也可以一次处理最多 100 张，单文件最大 8 MB。完成后可以逐个下载，也可以把整批打成一个 ZIP。
操作流程只有四步：
- 把 AVIF 文件拖入压缩区。
- 等待每个文件旁显示压缩前后的体积。
- 下载更小的结果，并与原图比较。
- 如果节省不明显，或画质代价不值得，就保留原图。
如果压缩结果反而更大，PiPic 会保留原文件。这一点对 AVIF 尤其重要，因为已经认真优化过的文件可能没有多少余量。
检查画质，不要只相信宣传语
AVIF 同时支持有损和无损压缩。实际用于 Web 交付时，有损编码很常见，因为它能带来更明显的体积下降。因此，“完全没有质量损失”并不是一个值得追求的承诺。更诚实的检查方式是：在图片真实使用场景里，这些变化是否看得见。
先按页面实际显示尺寸比较，再放大检查容易暴露问题的区域：
- 渐变与暗部阴影；
- 皮肤、头发、树叶等细密纹理；
- 文字或界面截图周围的锐利边缘；
- 透明区域与柔和边缘；
- 高饱和颜色与高光。
不要只看文件体积。只有结果仍能完成原本的视觉任务，更小才有意义。落地页的主视觉值得多检查一分钟；如果只是很小的缩略图，按实际显示尺寸检查通常就够了。
必要时保留备用格式
当前版本的 Chrome、Edge、Firefox、Opera 和 Safari 都支持 AVIF，但它的历史仍比 JPEG 或 PNG 短，旧软件可能无法打开。MDN 也建议在需要覆盖更老环境时准备备用格式；其图片格式指南列出了 AVIF 与传统格式的差异。
在网站中，可以使用 <picture> 让浏览器优先选择 AVIF，并在需要时回退到 WebP 或 JPEG：
<picture>
<source srcset="hero.avif" type="image/avif" />
<source srcset="hero.webp" type="image/webp" />
<img src="hero.jpg" width="1200" height="800" alt="" />
</picture>
不要删掉 width 和 height。它们能让浏览器在图片到达前预留空间，减少布局跳动。同时确认备用文件真的存在；指向不存在文件的 <source> 并不能提供兼容性。
把批量压缩当成交付步骤
优化一张首屏图有用，建立可重复的流程更有用。页面上线前，把该页面使用的 AVIF 资源集中起来，整批压缩，然后优先检查体积最大的几个结果，而不是随机打开文件。
可以使用这份简短清单：
- 尺寸符合页面中的最大显示需求；
- 输出仍是
.avif，线上返回image/avif； - 压缩前后的差异值得保留；
- 重要边缘、渐变和透明区域仍然正常；
- 需要时已经准备响应式版本和备用格式；
- 上线后的响应带有合理的缓存头。
如果图片长期放在仓库或构建流程中，可以使用 PiPic Agent CLI 把压缩变成自动化步骤。只是临时处理一个文件夹时，浏览器通常更直接：拖入文件、检查结果、下载 ZIP。
AVIF 很高效，但并不神奇。先给它正确的尺寸，再在不改变格式的前提下重新压缩，最后核验用户真正会看到的结果。这样才能在不靠猜测的情况下得到更小的 AVIF 文件。
