企业官网建设流程全解析

十月六日，Chrome 团队宣布从 Chrome 155 开始正式支持 JPEG XL 图片解码。

这距离谷歌把 JPEG XL 从 Chromium 里移除，已经过去三年多。

同一家公司亲手拔掉的功能，如今又亲手接了回来，这种反转在浏览器史上非常少见。

JPEG XL 是下一代图像格式，压缩率比 JPEG 高百分之三十到五十。

它还支持无损压缩、内置 HDR 高动态范围，以及无损的 JPEG 转码。

官方博客把回归的原因归结为安全、性能与开发者反馈三条主线。

其中最特殊的决策是安全：Chrome 没有用现成的 C++ 参考实现，而是用 Rust 重写了解码器。

Hacker News 上这篇公告拿到两百多个赞和一百多条评论，讨论集中在反转与生态。

评论区照例贴出了 xkcd 927 那张标准战争漫画，嘲讽格式之争的荒诞。

对国内开发者来说，这件事值得拆开看：为什么移除、为什么回归、以及 Rust 到底做了什么。

公告的三位作者都是资深工程师：Luca Versari、Moritz Firsching 与 Philip Jägenstedt。

前两位是 libjxl 参考实现的核心贡献者，第三位长期维护 Web 平台测试基础设施。

六年反转：从实验支持到亲手移除

时间倒回 2021 年，Chrome 还只是把 JPEG XL 放在实验开关后面。

那时候 WebP 已经普及，AVIF 正在快速上位，格式赛道非常拥挤。

2022 年底，Chromium 邮件列表上的讨论开始转向放弃 JPEG XL。

2023 年初，Chrome 110 正式把 JPEG XL 标记为弃用。

随后的版本直接移除了实验支持，社区一片哗然。

支持者指出，JPEG XL 在无损、HDR 与渐进式解码上有 AVIF 给不了的能力。

反对者则认为，AVIF 已经够用，再养一个格式的成本与风险都不划算。

移除之后，Chromium 的 issue 40270698 被开发者反复顶起。

这个 issue 成了整个格式议题里最热的一条，三年里一直没有关闭。

2026 年它终于被重新打开并实现，成为回归的直接起点之一。

值得注意的是，JPEG XL 标准本身是 JPEG 的官方升级，编号 ISO/IEC 18181。

它不是民间发明，而是 JPEG 委员会历时多年推出的正式标准。

JPEG XL 采用了模块化编码设计，把传统 JPEG 的离散余弦变换升级成可变尺寸的 VarDCT。

渐进式解码基于金字塔结构，可以按网络状况逐层细化。

这些设计让它对存量 JPEG 文件特别友好，转码可以做到字节级无损。

全网海量存量 JPEG 照片，因此有了近乎零损失的迁移通道。

这样的技术底子被 Chrome 砍掉，才让社区格外意难平。

当年移除：官方理由与社区猜测

当年的官方口径在 blink-dev 邮件列表里有完整存档。

核心判断是：开发者对 JPEG XL 的需求不足，AVIF 已经覆盖主要场景。

另一个理由是浏览器每多一个解码器，就多一块面向攻击者的表面。

从工程保守主义的角度看，这套说法有它的道理。

但社区对这个解释并不买账，评论区给出了好几套替代说法。

有人认为是联盟政治：谷歌加入 AOM 联盟后，需要力推自己参与制定的 AVIF。

也有人翻出旧账：JPEG XL 项目本身就是谷歌苏黎世员工发起的。

还有人断言，Chrome 只是不想养一个和 WebP 直接竞争的格式。

更尖锐的猜测是，当年移除与能力无关，纯粹是内部没人愿意为它背业绩。

这些猜测无法证实，但足以说明社区对这次移除的怨气有多深。

有意思的是，libjxl 贡献者榜单的前三名都是谷歌员工。

也就是说，谷歌当年砍掉的几乎是自己人维护的代码。

有开发者评论说，这就像公司砍了自己最熟的团队做的项目。

当年的反对派里，还有人担心 JPEG XL 重蹈 JPEG 2000 的专利覆辙。

评论区立刻有人纠正：JPEG XL 是开放标准，没有 JPEG 2000 那样的授权泥潭。

这些分歧后来都被摆到了 2026 年的回归决议上。

回归的三重推力

官方把回归归因于开发者反馈与互操作项目，这条线写得很明确。

反馈渠道包括 bug 报告、问卷调查与 Developer Signals 项目。

最显眼的是 Interop 项目，JPEG XL 在里面连续多年是热门提案。

2026 年的 Interop 提案列表里，JPEG XL 相关的 issue 拿下了大量开发者投票。

为了确保跨浏览器一致，谷歌参与了 Interop 2026 JPEG XL Investigation。

这个专项的目标是给 JPEG XL 的每个特性补齐测试，并让测试在各浏览器全部通过。

社区讨论里还补了一个更现实的推力：PDF 协会。

多名开发者指出，PDF 规范更新把 JPEG XL 采纳为图像压缩算法。

这意味着任何能渲染 PDF 的浏览器，都必须内置一个 JPEG XL 解码器。

既然解码器迟早要进浏览器，把它暴露给 img 标签只是顺水推舟。

三重推力叠在一起，回归就从要不要做变成了什么时候做。

苹果的动作也被视为关键变量：Safari 早在 2023 年就支持了。

浏览器阵营里谷歌成了最后补票的一个，姿态反而最隆重。

公告开篇没有废话，直接宣布 Chrome 155 开始解码 .jxl 文件。

随后才展开安全、性能与生态三部分说明，逻辑非常工程化。

jxl-rs：把解码器重写成 Rust

公告里最重头的工程决策，是用 Rust 从零重写解码器。

图像解码器处理的是网络上传来的不可信二进制，是浏览器的核心攻击面。

这类代码历史上出过大量越界读、堆溢出与释放后使用的漏洞。

Chrome 的安全模型依赖沙箱与纵深防御，但沙箱只是第二道防线。

官方明确说，要消除风险就得从源头下手，而不是靠沙箱兜底。

于是有了 jxl-rs，一个纯 Rust 的 JPEG XL 解码器实现。

团队还引入了 Chrome 的 rule of two 安全准则作为设计约束。

这条准则要求处理不可信数据时，风险因素最多叠加两种，避免语言与权限双重失控。

为了不牺牲性能，Rust 的 target_feature_11 特性被推动稳定。

这个特性让代码可以在不写 unsafe 的前提下直接使用 SIMD 指令。

SIMD 是编解码器性能的核心来源，以前几乎必须靠 unsafe 才能用好。

在这个基础上，团队建了一个叫 jxl_simd 的 SIMD 抽象层。

它借鉴了 C++ 的 Highway 库，而 Highway 本来就是为 libjxl 开发的。

最终 unsafe 代码被收敛到极少数经过重点审查的位置。

性能优化则直接继承 libjxl 的成果，包括跨区域边界的通用处理流水线。

流水线尽量减少数据拷贝，把硬件性能压榨到极限。

团队维护了一个公开的性能看板，跟踪不同硬件平台上的解码表现。

验证手段也拉满：模糊测试加 AI 代码审查双管齐下。

官方声称 jxl-rs 整个实现历史上没有发现任何内存安全漏洞。

这个结论附带了一个前提：AI 审查参与到了每一段关键代码。

对解码器这种高危代码来说，这是一个相当罕见的记录。

值得一提的是，jxl-rs 的基本盘还是当初实现 libjxl 的那批人。

同一批作者把 C++ 的成果用 Rust 重写了一遍，工程质量有延续性。

这也回应了社区的一个疑问：为什么不用现成的 libjxl 直接接入。

答案写在公告里：内存安全的收益，值得用一整次重写来换。

SIMD 性能工程：安全不能慢

内存安全之外，性能是决定成败的另一半。

一个安全但慢一倍的解码器，在浏览器里是没法上线的。

现代编解码器的性能关键，在于吃满设备的 SIMD 硬件。

传统方案是手写汇编或者大量 unsafe 包装，容易出错也难维护。

target_feature_11 稳定后，SIMD 代码可以直接写在安全 Rust 里。

jxl_simd 在此基础上做了一层跨平台抽象，一次编写多处编译。

抽象层的设计参考 Highway，接口风格对 libjxl 开发者很熟悉。

跨区域处理流水线来自 libjxl 的优化积累，不是从零发明。

区域边界的处理是解码器性能的经典瓶颈，这里做了专门优化。

整体策略是能少拷贝就少拷贝，能并行就并行。

性能看板公开在 jxl-rs-perf 站点，任何硬件平台的数据都能对比。

公告没有给出绝对的性能数字，而是强调与 libjxl 同档。

对浏览器来说，和参考实现同档已经足够说服团队上线。

社区对此的观感也不错：安全不是靠降速换来的。

这套安全加性能的组合，可能成为浏览器新格式落地的样板。

生态时间线：Safari、Firefox 与 iPhone

浏览器支持这件事，Chrome 其实是最后一个赶上的大厂之一。

苹果在 2023 年 9 月发布的 Safari 17 里就加入了 JPEG XL。

当时 macOS、iOS、iPadOS 与 watchOS 四个系统一起支持。

iPhone 16 系列甚至提供了把照片直接存成 JPEG XL 的选项。

去年的 iPhone 17 Pro 更进一步，ProRAW 模式支持 JPEG XL 有损与无损压缩。

Firefox 长期把 JPEG XL 藏在实验开关后面，很多用户以为它不支持。

2026 年 8 月，Firefox 157 传出将默认启用 JPEG XL 解码的消息。

它采用的同样是基于 Rust 的 jxl-rs，与 Chrome 共用一套解码器。

HN 评论预测 Firefox 会在十月进入稳定版，覆盖率因此跨过拐点。

也就是说，从十月起主要浏览器基本都认这个格式了。

但 caniuse 的数据显示，Safari 至今没开渐进式渲染与动画支持。

有开发者评论说，Safari 像乌龟，反而把兔子 Chrome 等到了。

Android 的 Chrome 何时铺开，取决于版本分发的现实节奏。

桌面端的图像软件支持也在缓慢跟进，生态还没到齐。

有开发者实测，iOS 27 的相册能正常处理 .jxl，而 iOS 18 不行。

macOS 27 的快速预览与缩略图也已正常工作。

系统级的支持方式还不一样：macOS 走的是系统共享库路线。

Chrome 与 Firefox 则各自静态链接，互不依赖。

共享库与静态链接之争，在评论区又吵了一轮。

支持方的核心论据是少一份重复实现，反对方则强调打包与安全维护成本。

这个分歧短期内不会有标准答案，但两种路线都活着。

AVIF 与 JPEG XL：什么时候选谁

新一代格式的竞争，核心是 AVIF 与 JPEG XL 谁更值得上。

开发者社区的经验是：低码率区间 AVIF 占优，高码率区间 JPEG XL 更强。

有人实测把会议论文集压成小缩略图，JPEG XL 明显好于 AVIF。

也有人长期用 AVIF，认为它在压缩率与画质上全面胜过 jpg 和 png。

无损场景几乎没有争议：JPEG XL 与 WebP 都远超 AVIF。

AVIF 的无损能力是短板，这也是它很难成为万能格式的原因。

JPEG XL 还有一个少见的能力：对 JPEG 文件的无损转码。

老照片直接转成 JPEG XL 可以做到字节级无损，存量 JPEG 资产因此多了一条保留通道。

AV1 编码器这几年进步明显，正在缩小有损区间的差距。

有 AV1 编码器作者认为，JPEG XL 编码器想再大幅进步并不容易。

但他也承认这只是个人判断，参考编码器的工作可能随时重启。

JPEG XL 正式落地之后，围绕参考编码器的开发资源有望重新聚拢。

对内容平台来说，最稳的路线是用 picture 标签按能力分发。

浏览器会自动选择认识的格式，老格式永远有兜底。

官方博客的态度也是都试试，并没有要求一刀切迁移。

官方还提醒，JPEG XL 最适合高保真、无损以及细粒度渐进式解码场景。

普通博客缩略图这种低码率场景，继续用 AVIF 完全合理。

有开发者总结：AVIF 适合预算紧张的场景，JPEG XL 适合较真的场景。

还有一层值得注意：AVIF 源自 AV1 视频编码，WebP 源自 VP8 视频编码。

JPEG XL 独立于视频编码体系，设计目标纯粹是图片。

格式之争最终会由生态决定，而不是单一跑分。

遗留问题与开发者的行动清单

新格式落地的第一课，永远是旧格式的历史教训。

WebP 已经十五岁，很多软件到现在支持得还很别扭。

有开发者指出，谷歌自己连 Google Docs 都不支持 WebP 上传。

聊天软件里 WebP 经常被当成贴纸，文件管理器预览也是时灵时不灵。

JPEG XL 目前的生态接受度比 WebP 同期好得多，但还没到齐。

天文影像开发者反馈，jxl-rs 解码器内部会重采样到八位。

十二位深度的科学图像，目前还得继续用 AVIF。

HDR 是 JPEG XL 的卖点，也成了新的争议点。

有用户抱怨 HDR 内容在移动端会突然拉高屏幕亮度。

格式之争还带出了扩展名问题：光看后缀分不清有损还是无损。

无损 JPEG XL 和有损 JPEG XL 共用 .jxl，只能靠工具标注。

评论区甚至有人提议用 .ll.jxl 这种民间后缀来区分。

对开发者来说，第一步是用 picture 标签做渐进增强，别替换现有图片。

第二步是给图片管线加 JPEG XL 编码测试，覆盖高保真与无损场景。

第三步是参与 Interop 2026 JPEG XL Investigation，帮忙补测试用例。

发现解码问题就按官方渠道提交 bug，组件号是 2071994。

<picture> <source type="image/jxl" srcset="photo.jxl" /> <source type="image/avif" srcset="photo.avif" /> <img src="photo.jpg" alt="示例照片" /> </picture>

去而复返的意义

这次回归最大的意义，不是 Chrome 多认识了一个格式。

而是浏览器厂商为安全而重写解码器，并把工程过程完整公开。

用 Rust 重写高危解码器，可能成为未来浏览器处理新格式的样板。

对 JPEG XL 本身来说，去而复返反而比一路顺利更有说服力。

它撑过了最主流浏览器三年的冷落，靠的是格式自身的能力。

开发者反馈、互操作测试与 PDF 规范，共同把它拉回了桌面。

风险也还在：谷歌会不会再次变心，没人能打包票。

但这次生态不再是孤军：Safari、Firefox 与系统层都在。

对普通开发者，建议把 JPEG XL 当作高保真与无损场景的第一候选。

对内容平台，建议先测渐进式解码的收益再决定迁移节奏。

一个格式的生死，最终由工具链与开发者的选择决定。

六年前谷歌说它没有需求，六年后同一家公司用官方博客把它请了回来。