Firefox 计划默认开启 JPEG XL，Rust 解码器解决安全后还要算性能账
Mozilla 工程师提交 Intent to Ship，计划从 Firefox 157 开始在所有平台默认启用 JPEG XL 解码。Firefox 使用 Google Research 开发的 Rust 解码器 jxl-rs，而不是此前让 Mozilla 担心攻击面的十万行多线程 C++ 实现。
作者：林岚｜OC 开发者生态编辑
Mozilla 工程师提交 Intent to Ship，计划从 Firefox 157 开始在所有平台默认启用 JPEG XL 解码。Firefox 使用 Google Research 开发的 Rust 解码器 jxl-rs，而不是此前让 Mozilla 担心攻击面的十万行多线程 C++ 实现。
一句话结论：JPEG XL 终于接近跨浏览器可用，但“默认支持”只解决兼容性，网站是否值得迁移仍取决于文件体积、解码时间、耗电和回退成本。
JPEG XL 想同时覆盖传统 JPEG、PNG、GIF 和部分 WebP、AVIF 场景，支持有损与无损压缩、HDR、动画和渐进显示。Safari 在 2023 年加入支持，Chrome 已使用相同 Rust 库进行开关后的测试，但尚未承诺正式发布。Firefox 从 152 开始把它放进 Labs，Nightly 默认开启；157 的计划意味着普通用户不再需要手动改偏好项。
Mozilla 最初不是不喜欢格式，而是不愿把巨大 C++ 解码器直接装进浏览器攻击面。图片解析器处理来自任意网页的不可信二进制数据，内存安全漏洞尤其危险。Mozilla 给 JPEG XL 团队提出的条件，是交付安全、紧凑、兼容且性能足够的 Rust 实现。jxl-rs 达到这个门槛后，Rust 不会让逻辑错误消失，但能减少越界访问和释放后使用这一类风险。
功能方面，Firefox 实现支持动画和渐进显示。渐进显示会在文件尚未下载完成时先呈现模糊轮廓，再逐步增加细节，对大图和慢网络很有价值。Mozilla 还准备在默认开启前再次模糊测试，并覆盖位深、Alpha、CMYK、颜色管理、损坏文件和分块解码等场景。
性能争议没有消失。Mozilla 工程师称，加入多线程补丁后，jxl-rs 在其机器上的大图解码接近甚至略快于 Safari 使用的 libjxl，小图差距更明显。讨论中的另一位开发者则用单线程无损测试得到 JPEG XL 比无损 WebP 慢约 30 倍、文件只缩小约 10% 的结果。两个结论并不必然矛盾：测试图片、尺寸、是否多线程、有损或无损都会改变结果。
所以开发者不该把“Firefox 支持”翻译成“现在应把全站图片转成 JXL”。更稳妥的做法是用真实图片集测试首屏时间、CPU、移动设备耗电和缓存命中，使用内容协商或 <picture> 提供回退，并观察 Chrome 是否正式跟进。格式胜负很少只靠压缩率决定，编码工具、CDN、编辑软件和浏览器解码稳定性同样重要。
关键事实
- 计划版本：Firefox 157，所有平台默认开启，仍属于发布意向而非已经落地的稳定版事实。
- 解码器：jxl-rs，以 Rust 编写。
- 已实现能力：动画、渐进显示、颜色管理和多种位深等。
- 浏览器状态：Safari 已支持，Chrome 在开关后测试但尚无正式发布承诺。
OC 判断
Mozilla 这次最值得肯定的不是“站队 JPEG XL”，而是先把解码器攻击面和测试补齐再默认开放。格式采用仍要让真实网站数据说话，单张样图的压缩率和单机跑分都不够。
为什么重要
- 对前端开发者：跨浏览器回退会更容易，但现在还不适合无条件替换现有格式。
- 对浏览器厂商：Rust 正从安全偏好变成复杂媒体解码器的准入条件。
- 对用户：更小图片可能节省流量，过慢解码也可能换来更高耗电。
评论
围绕这篇文章补充信息、提出问题或分享观察。