AVIF 是什么？一个你必须了解的现代图像格式
AVIF 究竟是什么
AVIF 的全称是 AV1 图像文件格式 (AV1 Image File Format)。它是一种用于静态图像的现代容器，源自于开放媒体联盟 (Alliance for Open Media) 开发的 AV1 视频编解码器——该联盟由谷歌、苹果、Mozilla、Netflix 和亚马逊等巨头组成。第一个稳定规范于 2019 年问世，从那时起，浏览器的支持率便稳步攀升。 要真正理解 AVIF，你得看看它的“家谱”。它的父辈 AV1 是作为一种免版税的视频编解码器而创建的，旨在挑战受专利限制的 HEVC (H.265)，后者正是苹果 HEIF 图像背后的技术。因为 AV1 是开源且免费使用的，任何开发者都可以实现它而无需支付许可费。这对推广普及来说是件大事。也正因如此，Chrome、Firefox 和 Edge 都原生支持 AVIF，而 HEIF/HEIC 在网络上的支持仍然一团糟。 AVIF 的工作原理是利用 AV1 的帧内编码工具，基本上是将一张图片当作视频的一帧来处理。这可不是什么廉价的捷径，而是让 AVIF 能够使用与 AV1 视频同样复杂的压缩技术，从而实现高效压缩：支持最大 64x64 像素的可变变换块大小、胶片颗粒合成、环路滤波等等。其结果是，这个格式能够与 JPEG XL 和 WebP 2 一较高下，争夺当今最高效图像格式的头衔。 除了压缩，AVIF 还是一个功能丰富的格式。它支持 8 位、10 位甚至 12 位的色深，以及 HDR 和像 Rec. 2020、Display P3 这样的宽色域。它还能处理 alpha 透明通道，甚至支持短动画。这种灵活性使它在处理照片和图形内容时都能表现出色，不过正如我们稍后会看到的，它有其特定的优点和缺点。
AVIF 与 JPEG、WebP 和 PNG 的压缩效果对比
数字比华丽的辞藻更有说服力。Netflix 在 2021 年的一项研究表明（他们作为 AV1 的主要开发者之一，对此应该很了解），在同等视觉质量下，AVIF 文件比 JPEG 小大约 50%。而谷歌自家的 WebP 通常比 JPEG 节省 25-34%。这可不是微小的、渐进式的改进，而是效率上的代际飞跃。 让我们具体化一点。一张高质量的 180 KB 产品照片，如果保存为 JPEG (质量 85)，作为 WebP 大约是 130 KB。而作为 AVIF，使用恒定码率因子 (crf) 30，同样图像的大小可能只有 90-100 KB，在好的显示器上看不出任何质量损失。如果你能容忍略低的质量，比如用作缩略图，crf 设置为 40 可以将文件大小降到 60 KB 以下。 那么图形呢？对于 Logo、插图和 UI 截图这类纯色块较多的图像，PNG 一直是无损压缩之王。AVIF 也有无损模式，但别想当然地认为它更好。根据我的经验，这对它来说是个糟糕的选择。无损 AVIF 文件通常比同等的 PNG 文件大 10-20%。相比之下，WebP 的无损模式不仅稳定地比 PNG 小约 26%，也优于无损 AVIF。结论很明确：AVIF 的真正优势在于照片的有损压缩，而非无损图形。 Alpha 透明通道是 AVIF 真正大放异彩的地方。JPEG 根本不支持透明。WebP 可以，但 AVIF 通常做得更好、文件更小。一张带有透明背景的产品图——这在电商领域是家常便饭——保存为 AVIF 可以比 PNG 小 60-70%，同时在头发或毛皮等棘手细节周围保持清晰、干净的边缘。
2025 年的浏览器和平台支持情况
AVIF 早已不是实验品。截至 2025 年中，根据 caniuse.com 的数据，全球浏览器支持率已超过 93%。Chrome 从 2020 年 8 月的 85 版本就开始支持。Firefox 在 2021 年 10 月的 93 版本加入。至关重要的是，macOS Ventura 和 iOS 16 及更高版本上的 Safari 也能解码 AVIF。而基于 Chromium 的 Edge 自 2020 年末也已支持。 这对你意味着什么：如果你在网站上使用 AVIF 图像，几乎所有人都能看到它们。剩下约 7% 使用旧版浏览器的用户只需要一个后备方案。优雅的标准解决方案是 HTML 的 `<picture>` 元素： <picture> <source srcset="image.avif" type="image/avif"> <source srcset="image.webp" type="image/webp"> <img src="image.jpg" alt="产品照片"> </picture> 这个简单的三层后备方案覆盖了所有主流浏览器。不支持 AVIF 的浏览器会尝试 WebP；如果再失败，它会回退到通用的 JPEG。它就这么好用，无需 JavaScript。 在桌面上，情况稍微复杂一些，但大体上是积极的。Windows 11 在从微软商店免费安装 AV1 视频扩展后，可以在其“照片”应用中显示 AVIF。macOS 从 macOS Monterey 开始在“预览”中提供原生支持。Adobe Photoshop 在 23.2 版本（2022 年 2 月）中集成了 AVIF 支持，所以你可以直接打开和保存。GIMP 从 2.10.22 版本开始支持。甚至 Figma 也能打开 AVIF 文件，尽管目前还不能导出。 对于需要构建自动化工作流的人来说，服务器端的工具已经很成熟。像 libavif (参考实现)、用于 Node.js 的 Sharp、用于 Python 3.10+ 的 Pillow，以及 ImageMagick 7.1+ 等关键库都提供了可靠的 AVIF 编码和解码能力。
何时使用 AVIF——以及何时不该用
那么，到底应该在哪些地方使用 AVIF？主要目标是网络上任何文件大小会影响性能的照片类图像。想想电商产品 галерея、新闻文章的主图以及作品集网站。如果你的网站每天提供数千张图片，切换到 AVIF 可以将你的 CDN 带宽成本削减 30-50%。这在规模化应用中可是实实在在的钱。 HDR 摄影是另一个杀手级应用场景。凭借其对 10 位和 12 位颜色以及 Rec. 2020 等宽色域的支持，AVIF 可以显示 HDR 内容，而无需先将其压缩成 SDR。JPEG 完全做不到这一点，而 WebP 则被限制在 8 位。对于摄影师或向拥有 HDR 屏幕的用户展示高端图像的房地产网站来说，AVIF 是唯一被广泛支持的、能不辜负硬件性能的网络格式。 但它并非万能灵药。最大的缺点是 AVIF 编码速度很慢。真的很慢。以高质量设置编码一张高分辨率照片，可能会让你的 CPU 风扇狂转并花费数秒钟，而 JPEG 的编码只需几毫秒。这种延迟使得 AVIF 不适合需要实时生成图像的应用，比如需要频繁保存的照片编辑器。虽然硬件编码支持正在改善，但纯软件编码仍然是一个显著的瓶颈。 对于其他任务，你应该用合适的工具。矢量图形和图表仍然属于 SVG。对于代码或 UI 文本的截图，当你需要绝对像素级的清晰度时，坚持使用 PNG 或无损 WebP。而对于任何与印刷相关的东西，AVIF 完全不沾边；TIFF 和 PDF 仍然是无可争议的标准。 那么动画呢？AVIF 支持动画（作为 AVIS 序列），但编码比静态图像更慢，而且浏览器支持的可靠性也较低。老实说，你最好还是使用动画 WebP，或者更棒的是，一个设置为自动播放的短 MP4 或 WebM 视频文件。
如何将图片转换为 AVIF
好了，那到底该怎么制作这些文件呢？你有几个选择，具体取决于你的需求。 对于开发者和命令行爱好者，`avifenc`（来自 libavif 工具包）是参考编码器。一个典型的命令可能是：`avifenc --min 20 --max 40 --speed 6 input.jpg output.avif`。`--min` 和 `--max` 标志设置质量范围（0-63 的范围内，数值越低质量越好），`--speed` 控制编码时间和文件大小之间的权衡（0 最慢但效率最高，10 最快）。对于批量处理，速度设置为 6 是一个很好的起点。 如果你想看到自己正在做什么，谷歌的 Squoosh (squoosh.app) 是一个了不起的浏览器内工具。它让你通过一个可视化的质量滑块和一个即时的并排比较来调整 AVIF 设置。它非常适合一次性的转换，以及让你感受质量设置如何影响你的特定图像。 对于不想接触命令行的批量转换，CocoConvert 提供 AVIF 作为输出格式，支持 JPEG、PNG、WebP 和 HEIC 等源文件。你只需上传文件，选择 AVIF，然后下载结果。其编码器经过预先配置，为网络使用在大小和质量之间取得了很好的平衡。坦白说，有个小缺点：CocoConvert 没有提供手动控制恒定码率因子 (crf) 或色度子采样的选项。如果你需要那种精细的控制——比如说，为了保证专业照片的 4:4:4 色彩——命令行工具或 Photoshop 的导出对话框会给你这种精度。 在 Photoshop (CC 2022 及更高版本) 中，只需转到 文件 > 导出 > 导出为，然后从格式列表中选择 AVIF。然而，Lightroom Classic 仍然不能原生导出 AVIF，需要第三方插件来弥补这个差距。
AVIF vs. JPEG XL：另一个竞争者
任何对 AVIF 的诚恳讨论都必须承认它的主要对手：JPEG XL (JXL)。这是一个极好的格式，提供了一些 AVIF 无法做到的事情，比如真正的无损 JPEG 重压缩（你可以将 JPEG 转换为 JXL 再转回来而没有任何质量损失）以及在相当质量水平下更快的编码速度。在处理包含清晰线条和文本的图像时，它通常也做得更好。 在压缩性能的正面交锋中，没有哪个格式是全方位的明确赢家。在非常低的比特率下，AVIF 通常在处理细节丰富的照片时领先，而 JPEG XL 则在图形、文本密集的图像以及任何看重编码速度的工作流中表现更佳。 但技术规格并不能说明全部问题。关键的区别在于浏览器支持。2023 年，Chrome 的开发者以缺乏生态系统兴趣为由，移除了对 JPEG XL 的实验性支持，这个决定实际上冻结了市场。截至 2025 年中，只有 Safari (17+) 原生支持 JXL，Firefox 的支持则隐藏在一个标志后面。这意味着你今天无法在网络上可靠地提供 JXL，除非使用 JavaScript polyfill。对于 Web 开发者来说，这至少在目前为我们做出了决定。拥有 93%+ 原生支持率的 AVIF，是现代图像部署的唯一实际选择。 这种情况可能会改变。JPEG XL 社区充满热情且活跃，浏览器厂商可能会重新考虑。但对于任何正在构建网站的人来说，AVIF 拥有一个巨大且不可否认的优势：它在关键的地方得到了实际支持。
你应该将现有图片迁移到 AVIF 吗？
那么，你应该转换你的整个图片库吗？好消息是，迁移不必是一场要么全有要么全无的苦差事。对大多数人来说，最好的策略是简单地在你现有的 JPEG 和 PNG 旁边添加 AVIF 版本，使用 `<picture>` 元素让浏览器选择最佳格式。这意味着你不必删除旧文件，只需对它们进行增强。 对于一个拥有大型图库的网站，批量转换是唯一理智的做法。使用像 Node.js 的 Sharp 或 shell 循环中的 ImageMagick 这样的工具设置一个脚本，或者使用 Vite 或 webpack 的构建步骤插件。让它通宵运行。缓慢的编码是一次性成本，但节省的带宽会在每一次页面加载中带来持续的回报。 对于所有未来的新图片，工作流程甚至更简单。将为 Web 交付编码一个 AVIF 版本作为标准做法。保留你的原始高分辨率源文件——无论是 RAW、TIFF，还是高质量的 JPEG——并在发布过程中生成 Web 优化的 AVIF。 存储空间呢？是的，为每张图片保留多个版本会暂时增加你的存储占用。AVIF 文件更小，但你是将它们添加到现有库中。然而，对于大多数网站来说，CDN 出口带宽的大幅节省将轻易抵消源存储成本的微小增加。 最后一句忠告：关于存档。任何曾试图打开一个 15 年前的专有文件格式的人都知道数据腐烂和技术过时的痛苦。AVIF 还很年轻。JPEG 已经有 30 多年历史，并且将被尚未发明的软件所读取。对于你最重要图像的长期、永久存档，保守的选择是正确的。坚持使用高质量的 JPEG 或 TIFF。使用 AVIF 进行交付，但始终将你的原件保存在一个有可靠历史记录的格式中。