Chrome 155 稳定版发布：原生解码 JPEG XL、量子加密，WebGPU新能力
来源：Chrome for Developers（版本说明与 WebGPU 更新公告） 官方入口：https://developer.chrome.com/release-notes
结论先行
Chrome 155 稳定版于 2026 年 10 月向全平台推送。这一版有三条独立的更新线：
- 平台层：原生解码 JPEG XL、网页应用窗口控制、Digital Credentials API、隐藏 iframe 的音频策略收紧、媒体播放中心一键截图；
- WebGPU（155 与 156 合计）：WGSL
fragment_depth扩展、非对齐纹理压缩、srgb-linear与display-p3-linear两种线性色彩空间、snorm10-10-10-2顶点格式； - 安全：后量子加密算法 ML-KEM 与 ML-DSA 落地，另有 ChaCha20-Poly1305 与 X-Wing，并修复 247 个漏洞（其中 4 个为严重等级）。
对 Web3D 从业者来说，真正要关注的是中间那条。平台层的变化大多和渲染无关，而 WebGPU 那四条里有两条直接影响颜色管线和顶点数据布局——这是会落到你代码里的东西。
来源说明
本文综合两个官方来源与一家中文媒体的整理：
- Chrome for Developers 的 Release notes（Chrome 155 的完整说明在 Chrome Status 上）
- Chrome for Developers 博客《WebGPU 的新变化（Chrome 155-156）》，作者 François Beaufort，2026-10-07
- 中文报道：DoNews、IT之家转载的 Chrome 155 更新内容汇总（2026-10）
需要说明的是：WebGPU 那四条目前只有官方给出的标题级描述，还没有逐条的 API 文档与示例。下面第 2 节的解释基于 WebGPU 规范常识，具体 API 形态请以官方文档为准，我们会在正式文档发布后补充细节。
要点解读
1. 平台层的五处变化
| 变化 | 说明 |
|---|---|
| JPEG XL 原生解码 | 网页可直接显示 image/jxl，支持渐进式解码、宽色域、HDR、高位深与动画 |
| 网页应用窗口控制 | 获授权使用窗口管理权限的 PWA 可最大化、最小化、还原窗口，也能控制窗口能否调整大小 |
| Digital Credentials API | 网站可发起把数字凭证写入电子钱包的流程 |
| 隐藏 iframe 音频策略 | 收紧不可见 iframe 的音频播放行为 |
| 媒体播放中心截图 | 打开媒体播放中心后，画中画切换按钮旁新增截图按钮，一键保存当前视频帧，画面不含播放器界面元素 |
另外 Chrome 还调整了个人资料创建界面（Windows 用户首次启动会看到新的介绍步骤，Linux 与 macOS 用户预计在 Chrome 158 获得）。
2. WebGPU 拿到的四条新能力
这一版的 WebGPU 更新把 155 与 156 合并发布，共四项：
① WGSL fragment_depth 扩展
片元着色器可以输出深度值。在 WebGL 时代，片元着色器写深度是被限制的；WebGPU 从设计上允许，但之前需要走 @builtin(frag_depth) 且受若干约束。这条扩展的具体作用范围，需要等正式文档确认——但它属于自定义深度写入这一类能力，与阴影、软粒子、体积雾这些效果直接相关。
② 非对齐纹理压缩
压缩纹理格式（如 BC、ASTC、ETC2）通常要求资源尺寸按块对齐（4×4 或更大）。这条改动放宽了约束，意味着贴图尺寸不再必须凑成块大小的整数倍。对资源管线来说，这能省掉一部分为了对齐而做的 padding，尤其是那些尺寸不规则的 UI 贴图与图集。
③ srgb-linear 与 display-p3-linear 两种线性色彩空间
WebGPU 此前已有 srgb 与 display-p3。这次补上的是它们的线性版本——线性色彩空间是光照计算的正确工作空间，因为 sRGB 的传递函数是非线性的，直接在 sRGB 空间做插值和光照会得到偏暗或偏亮的结果。
对做 PBR 的人来说这条最有价值：它省掉了一次手动的线性化转换。配合 Chrome 155 同时加入的 Canvas 线性色彩空间支持，从纹理采样到画布呈现这一整条链路可以在线性空间里走通。
④ snorm10-10-10-2 顶点格式
这是把归一化的有符号 10 位三分量加 2 位分量打包进 32 位。用途是用更少的字节表达顶点属性——典型场景是法线、切线这类取值范围在 [-1, 1] 且精度要求不高的数据。
值得一提：这个格式进入 WebGPU 规范的过程，本站此前已跟进过（对应 gpuweb 仓库的一次规范提交）。这次是它随 Chrome 155 落到实现层。
3. 这几条对 Web3D 项目意味着什么
把上面四条按"能不能立刻用上"排个序：
| 能力 | 立刻可用性 | 适用场景 |
|---|---|---|
| 线性色彩空间 | 高 | PBR 材质、需要颜色准确的展示项目 |
| snorm10-10-10-2 | 中 | 顶点数据量大、显存吃紧的场景 |
| 非对齐纹理压缩 | 中 | 贴图尺寸不规则的资产管线 |
| fragment_depth 扩展 | 待确认 | 阴影、软粒子、体积效果 |
需要注意的是浏览器版本覆盖问题：这些能力随 Chrome 155 提供，而 Chrome 的稳定版覆盖率虽然高，但企业内网、政务终端、老旧设备上的浏览器版本往往滞后。做交付项目时，"能不能用"取决于你的最低支持版本定在哪，而不是最新版 Chrome 有什么。
4. JPEG XL 回归：一个被谷歌自己拔掉又接回来的格式
这次更新里被媒体提得最多的是 JPEG XL，但它其实有一个有意思的背景：Chrome 团队曾在三年多前把 JPEG XL 从 Chromium 中移除，这次又亲手接了回来。
按官方说明，Chrome 155 从 10 月 6 日起正式支持 JPEG XL 解码。这个格式的卖点：
- 压缩率比 JPEG 高约 30%–50%；
- 支持无损压缩与无损转码（可从现有 JPEG 无损转成 JXL）；
- 内置 HDR 支持、宽色域、高位深；
- 支持渐进式解码与动画。
对 Web3D 站点的实际意义：站内图片资源（封面、正文配图、纹理）如果换成 JXL，可以在同等视觉质量下显著减小体积。但先别急着换——浏览器支持目前只有 Chrome，Safari 与 Firefox 尚未跟进，直接替换会导致其他浏览器用户看不到图。合理做法是保留 JPEG/WebP 作为主格式，JXL 作为可选增强。
5. 顺手澄清一个流传很广的错误说法
搜索相关资讯时，会看到不少文章写「WebGPU 规范已于 2026 年 9 月正式成为 W3C Recommendation」。这是错的。
查 W3C 官方页面（https://www.w3.org/TR/webgpu/），WebGPU 规范当前的状态是 Candidate Recommendation Draft（候选推荐草案），并未成为 Recommendation。
另一批来源说「2026 年 1 月 WebGPU 进入 Web 平台 Baseline」——这个说法与 Safari 26（2025 年 9 月）和 Firefox 141（2025 年 7 月）先后上线 WebGPU 的时间线吻合，可信度较高。
这两件事容易混为一谈：浏览器实现层面的大面积可用（Baseline），和规范层面的定稿（Recommendation），是两条独立的进度线。写技术文章时把前者说成后者，是常见的事实错误。
本站判断
第一，这次更新对 Web3D 的实质影响集中在色彩空间。 线性色彩空间与 Canvas 线性色彩空间这两条，解决的是"颜色算不对"这个长期存在的工程麻烦。做 PBR 或需要颜色准确的项目，值得专门验证一遍。
第二，别把"Chrome 有了"当成"项目能用"。 交付类项目的最低支持版本通常由客户环境决定，而不是由 Chrome 的发布节奏决定。新增能力应该做特性检测 + 降级，而不是直接依赖。
第三，JPEG XL 值得观察但不值得现在迁移。 只有一家浏览器支持时替换主格式，收益是体积、代价是一部分用户看不到图。等 Safari 或 Firefox 跟进后再评估更划算。
第四，官方这次只给了标题级说明，这本身是个信号。 WebGPU 的四项能力合并两个版本一起发，说明这个 API 已经过了"每个版本都有大动作"的阶段，进入细节打磨期。这对生态是好事——意味着 WebGPU 的基础面已经稳定，增量开始集中在色彩、格式这类"最后一公里"问题上。
参考来源
- Chrome for Developers：Release notes（Chrome 155 的完整说明见 Chrome Status）
- Chrome for Developers 博客：《WebGPU 的新变化（Chrome 155-156）》，François Beaufort，2026-10-07
- Chrome for Developers：Chrome 中的新变化
- W3C：WebGPU 规范（当前状态：Candidate Recommendation Draft）
- 中文报道：DoNews《Chrome 155 正式发布：原生支持 JPEG XL 与后量子加密》（2026-10）
