JPEG XL 的回归到底有多真实 — Chromium 反转决定8个月后，从源头核实的现状

引言 — "回归了"和"能用了"是两回事
简短回顾 — 2022年发生了什么
2025年11月22日 — 发布在四年前那条帖子里的反转
真正进入 Chrome 的东西 — 用 Gerrit 追踪
Firefox — 同一个解码器，慢半拍
Safari 与 Interop 2026 — 剩下拼图的准确位置
截至今天的状态表
实务判断 — 现在该做什么、不该做什么
结语
参考资料

引言 — "回归了"和"能用了"是两回事

从2025年11月底开始，"Chrome 决定重新支持 JPEG XL"这类文章开始流传，2026年初又出现了"JPEG XL 已经进入 Chrome 145"的说法，最近甚至有"Firefox 152 也支持了"的消息。这些说法都在某种程度上是事实。而如果你就此信以为真，把 .jxl 部署到生产环境，那就会出事故。

图像格式支持这个话题上，传闻和实际状态之间的差距特别大。"代码在树里了""在标志位后面""在 Nightly 上默认启用""在正式版里默认启用"，这些全都是不同的阶段，但新闻标题把这种区分抹平了。所以本文不看报道，只看一手来源 — Chromium Gerrit 上已合并的 CL、源码树里实际的门控、Bugzilla 的里程碑，以及浏览器厂商的官方发布 API。本文梳理截至今天(2026-07-17)JPEG XL 究竟走到了哪一步，以及从业者应该在什么时候采取行动。

格式本身(相对 AVIF 的压缩效率、无损 JPEG 重新压缩之类的功能比较)已经在2026 图像格式全面解析一文中讨论过了，这里只问一个问题 — 它有没有真正进入浏览器。

简短回顾 — 2022年发生了什么

按时间顺序梳理如下。

2021年，Chromium 把基于 libjxl(C++)的实验性解码器放在标志位后面，并在 blink-dev 上发起了 Intent to Prototype 帖子。
2022年10月，同一个帖子里出现了移除公告。要点有三 — 实验性标志位不会无限期保留；整个生态系统的关注度不足以支撑继续实验；相对现有格式的增量收益不足以证明默认启用的合理性。
代码和标志位真正在 Chrome 110 中被移除。根据Chrome 官方版本历史 API，110 的稳定版推送始于2023年2月1日。

此后三年间，这项决定一直是 Chrome 问题追踪器上最喧闹的图像格式争论。与此同时，外部局势在变化。Apple 在 Safari 17 发行说明(2023年9月)中明确写入了新增 JPEG XL 支持 — 时至今日，它仍是唯一一款默认启用支持它的主流引擎。Mozilla 在其官方标准立场文档中，position 本身维持 neutral，但在理由说明里写明了这样的意思 — "再添加一个 C++ 图像解码器的成本，收益还不足以证明其合理性；但如果是内存安全的解码器，这个成本会大幅下降，只要实现满足我们的要求，我们愿意将其上线。"外界常说"Mozilla 已经转为 positive"，但它登记的立场至今仍是 neutral — 准确的说法是"有条件的开放"。

而恰好出现了符合这个条件的东西 — libjxl 团队打造的纯 Rust 解码器 jxl-rs。仓库自己的介绍是"以符合规范、安全、速度为目标、仍在进行中(work-in-progress)的重新实现"。这个"进行中"的限定语，在后文会再次变得重要。

2025年11月22日 — 发布在四年前那条帖子里的反转

这份反转公告不是新博客文章，而是作为回复发在了 2021 年那条 Intent to Prototype 帖子所在的同一条 blink-dev 帖子里。作者是 Rick Byers，以 Chrome ATL(Architecture Tech Leads)名义署名。内容概括如下：

自上次评估以来情况发生了变化 — Safari 已经上线，Firefox 更新了立场，开发者信号(bug 点赞数、Interop 提案、调查)持续被观察到，还有 JPEG XL 将被加入 PDF 标准的公告。
基于这些信号: "we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder"(我们欢迎为集成一个性能良好、内存安全的 JPEG XL 解码器所做的贡献)。
但要默认启用，需要有长期维护的承诺，一旦满足这一点以及通常的发布标准，就会将其纳入 Chrome。

仔细拆解这句话，这并不是"我们来做"，而是"如果有人做出来，并承诺持续维护，我们就会接纳"。回想一下，2022年移除的核心论据正是维护负担，这其实是一贯的态度 — 只在自己不承担负担的条件下才打开这扇门。理解了这个结构，才能正确解读之后八个月的推进速度。

真正进入 Chrome 的东西 — 用 Gerrit 追踪

仅用已合并的 CL 和官方日程来画出时间线，会是这样。全部内容都可以在 Chromium Gerrit 上核实。

2025-11-22  在 blink-dev 上发布有条件反转公告 (Chrome ATLs)
2025-12-10  将 jxl-rs 引入 third_party 供应链 — CL 7201443，+73,908 行
2025-12-28  新增 JXL 基础设施: 枚举与构建标志
2026-01-08  新增基于 jxl-rs 的 JXL 图像解码器 (被 revert，01-09 后 reland)
2026-01-13  解码器接线(wire up)+ feature flag 门控 + 新增 WPT 测试
2026-01-16  开始向打上 [M145] 标签的 145 分支做 cherry-pick
2026-02-10  Chrome 145 稳定版 (chromiumdash 官方日程) — 这是 M110 之后
            JPEG XL 解码器首次回到稳定版二进制文件中
2026-02-24  DevTools 集成 (JXL 禁用模拟、暴露 host config)
2026-01~04  jxl crate 版本反复升级，0.1.4 → 0.4.3
2026-05-07  将 chrome://flags 条目的过期时间延长到 M152
2026-06-28  截断文件渲染、动画崩溃等稳定性修复仍在持续合并中

有几点值得指出。

首先，门控有三层。 从源码来看，编译开关是 gn 参数 enable_jxl_decoder，默认值为 true，所以官方构建里包含了解码器。但运行时由 blink::features::kJXLImageFormat 掌控，截至今天的 main 分支，这个 base::Feature 是 FEATURE_DISABLED_BY_DEFAULT。用户唯一的开启方式是 chrome://flags 里的 enable-jxl-image-format 条目。简而言之，从 Chrome 145 到 151(当前稳定版)，二进制文件里有解码器，但默认是关闭的。

其次，"欢迎贡献"这个模式被逐字执行了。 flag-metadata.json 里登记的这个标志位的所有者，不是 Google 员工，而是一位外部贡献者(helmut@januschka.com)。事实上，最初基于 C++ libjxl 的实现在评审中收到"改用 Rust"的反馈后被放弃，改用 jxl-rs 重新实现的过程，被记录在贡献者本人撰写的回顾文章里。那篇文章里作者自己的测量数据(2025年12月，基于 jxl-rs 社区做了 26 个 SIMD 优化 PR 之后的版本)显示，在 3 张测试图片中有 2 张仍然是 C++ libjxl 更快(例如在一张 2048x2560 的照片上，jxl-rs 用时 198ms，对 libjxl 的 170ms)，而在剩下 1 张上 jxl-rs 快了 3 倍以上。这终究只是对几张特定图片的个人测量，难以一般化，但至少可以读出"Rust 解码器还没有全面变快"这个方向性的结论。

第三，发布流程根本还没开始。 chromestatus 条目里的 Chrome 状态仍然是 "Proposed"，也没有 Intent to Ship 帖子。5月，标志位的过期时间被延长到了 M152，而按 chromiumdash 的日程，152 的稳定版是在2026年8月25日。这次延长的意思是"在那之前先保持标志位状态"，而不是"在 152 中发布" — 延长标志位过期时间只是例行的日常维护。直到6月底，还有修复截断文件的部分渲染、查询动画重复次数时崩溃之类问题的 CL 在持续合并，这个事实更准确地说明，这段代码现在还处于"稳定化中"阶段，而不是"默认启用候选"阶段。

Firefox — 同一个解码器，慢半拍

Firefox 那边的进展，可以通过 Bugzilla 的里程碑精确定位。

Bug 1986393(2025-09-02 创建，FIXED，里程碑 149): "落地初版 jpegxl rust 代码，pref 保持关闭"。有意思的是，这比 Chromium 的反转公告早了两个多月 — Mozilla 一旦满足了自己设定的条件(内存安全的解码器)，就已经悄悄先动手了。
Bug 2016688(FIXED，里程碑 152): "在 beta/release 构建里也编译 jpeg xl 代码"。实际上，ESR 140 的 moz.configure 里仍然保留着只在 Nightly 编译的条件，而在 152 发布分支里这个条件已经消失，所有渠道都会编译。
但是，StaticPrefList.yaml 里 image.jxl.enabled 的默认值是 @IS_NIGHTLY_BUILD@。也就是说，2026年6月16日发布的 Firefox 152 正式版里，解码器已经编译进去了，但 pref 是关闭的，得在 about:config 里手动打开才能生效。152 的官方发行说明里没有提到 JPEG XL — "Firefox 152 支持 JPEG XL"这类文章标题和实际出货状态之间的差距，恰好就是这么大。

有一点值得留意: Firefox 的 Cargo.lock 锁定的解码器是 jxl crate 0.4.3，也就是和 Chromium 引入的同一个 libjxl/jxl-rs。两个引擎共享着同一个第三方解码器实现。回想一下，2022年移除的论据之一是"每个浏览器都要多背一个 C++ 解码器的维护负担" — 如今这个负担的结构本身已经变了。现在，一个仓库里的安全性和性能改进，会同时流向两个浏览器。

当然，未完成的清单在源码里也一览无余。追踪用的元 bug 1539075 于2019年开启，至今第7年仍处于 ASSIGNED 状态(最后一次活动是在本文发布的两天前)，mac x86_64 上解码变慢 3 倍的问题的变通方案还没解决(bug 2043091)，而让色彩空间通过 CICP 枚举来识别、而不是靠合成 ICC 配置文件(bug 2055224)这类质量问题，这周也还在新增登记。

Safari 与 Interop 2026 — 剩下拼图的准确位置

Safari 在这个故事里不是变量。从2023年9月的 Safari 17 开始就默认支持，Byers 的公告里列出的第一条依据也是 Safari。

更需要谨慎解读的是 Interop 2026。坊间流传"JPEG XL 已被纳入 Interop 2026"的说法，但查看官方 README 就会发现，JPEG XL 是一项 investigation effort，而不是计分的 focus area。文档本身也承认，目前针对它的 Web 平台测试还很稀少，今年的目标定为"让这个功能变得可测试"，甚至连开发者很看重的 progressive rendering，浏览器该在何时以何种方式执行，也仍在争论之中。这意味着现在还不是给互操作性打分的阶段，而是在制定评分标准本身的阶段。实际上，今年上半年 Gerrit 和 Bugzilla 两边，都在持续有向 jpegxl WPT 目录填充测试的提交流入 — 方向是对的，但没有人承诺完成的时间点。

截至今天的状态表

总结一下，截至2026年7月17日，现状如下。

                          解码器已编译    默认启用    手动启用方式
Chrome 151 (稳定版)           O           X       chrome://flags 的
                                                   enable-jxl-image-format
Firefox 152 (发布版)          O           X       about:config 的
                                                   image.jxl.enabled
Firefox Nightly (154)         O           O       -
Safari 17+                    O           O       -

Intent to Ship (Chromium):    无 (chromestatus 状态为 "Proposed")
正式版默认启用日程:            没有任何引擎公布过
Interop 2026:                  investigation effort (不计分)

"三年来首次，三大引擎的代码库中都存在 JPEG XL 解码器"这句话，和"绝大多数网络流量中 JPEG XL 依然不会被渲染"这句话，同时为真。把这两句话一起放在手里，才是眼下对这个话题的准确理解。

实务判断 — 现在该做什么、不该做什么

先说现在不该做的事。 把面向用户的 Web 图像格式切换成 JPEG XL。由于 Chrome 系列和正式版 Firefox 都默认不支持，如果不做 content negotiation 就直接输出 .jxl，大多数用户看到的会是破损的图片。也有用 WASM polyfill 来绕过的选项 — 前面那篇回顾文章的作者做的 polyfill，按作者自己的说法，gzip 后大约 540KB — 但为了省下几十 KB 的图片体积去搭载一个 540KB 的运行时，在大多数 Web 性能场景里是本末倒置。polyfill 真正值得用的地方，是那些已经大量持有 JXL 原始文件的特殊查看器类应用。

现在值得先做的事。 第一，检查你的图像流水线是不是已经具备 <picture> 或基于 Accept 头的格式分流机制。从 WebP 迁移到 AVIF 时搭建的那套结构，原封不动就能成为接纳 JXL 的通路 — 只是多加一种格式而已。第二，把 Accept: image/jxl 在 CDN 或源站日志里出现的比例，加进你的观测指标里。Safari 用户和已经打开标志位的用户已经在发送它了，这个比例出现阶梯式跳升的那天，就是某个浏览器改了默认值的那天。第三，把判断信号挂在一手来源上，而不是新闻上。真正的信号只有两个 — blink-dev 上出现"Intent to Ship: JPEG XL"，以及 Firefox 的 image.jxl.enabled 默认值在没有 Nightly 条件的情况下变成 true 的那次提交。在这两者之一发生之前，其余的一切都只是热身。

另外补充一点，这个案例还有一个和格式本身无关的教训。2022年的移除，不是因为"质量差"，而是因为"没有足够理由去承担维护负担"；2025年的反转，也不是由基准测试促成的，而是由维护负担的结构本身发生变化(内存安全的共享解码器 + 外部贡献 + 维护承诺)所促成的。在把一个功能塞进浏览器这件事上，技术优劣的争论其实并没有想象中那么关键，维护经济学才是那个常数。

结语

"JPEG XL 回归了"这句话准确的版本是这样的 — Chromium 附带条件打开了这扇门，外部贡献者和 libjxl 团队打造的 Rust 解码器从这扇门走了进去，Firefox 早一步开始搭载同一个解码器，而 Safari 从一开始就没有离开过。但截至2026年7月，没有任何一个引擎改动过正式版的默认值，也没有任何一个引擎公布过要改动的日程。

所以现在该做的不是切换，而是观测。把格式分流的结构整理好，盯紧 Accept 头，等待 Intent to Ship 这一个真正的信号出现 — 这就是截至今天，从业者对 JPEG XL 能够采取的最诚实的立场。