JPEG XL（JXL）的争议并不在于它是不是一个优秀的图像格式。作为 JPEG 的正式升级，它比 WebP 更通用，还能对现有 JPEG 做无损重编码，这些能力对存储平台、图片 CDN 和数字资产管理系统都很有吸引力。真正的问题是：技术先进，是否足以让它成为浏览器必须长期维护的基础能力？
Chrome 在 2023 年拒绝继续推进 JXL 后，讨论迅速分成两派。一派认为浏览器错过了更好的格式，另一派则认为，在需求尚未形成之前引入新解码器，只会增加兼容性、安全和维护负担。要理解这个决定，不能只比较压缩率。
浏览器支持不是一场编码器跑分
图像格式在实验室里通常比较文件大小、视觉质量、编码速度和解码速度。但浏览器面对的是另一张成本表。
每增加一种格式，浏览器厂商都要长期承担：
- 解码器及其依赖的安全审计与漏洞修复；
- 不同操作系统、CPU 架构和内存条件下的测试；
- 色彩管理、透明度、动画、元数据等边界行为；
- 与缓存、开发者工具、自动化测试和内容协商的集成；
- 在移动设备上的耗电、内存峰值与硬件加速问题；
- 一旦网页开始依赖该格式，几乎无法撤销的兼容性承诺。
因此，“JXL 比现有格式更强”并不能直接推出“浏览器应该默认支持 JXL”。浏览器还需要看到足够明确的用户收益、站点采用意愿，以及无法通过现有格式解决的问题。
这里存在典型的网络效应：网站不部署，是因为浏览器支持不完整；浏览器不愿部署，是因为网站使用量太低。标准在技术上成熟，并不代表它已经跨过生态采用的门槛。
JXL 最有价值的能力，未必需要浏览器参与
JXL 的无损 JPEG 重编码尤其值得运维团队关注。它允许系统在保留恢复原始 JPEG 能力的前提下，以 JXL 形式存储资产。对于拥有数千万张历史图片的平台，这可能意味着无需重新裁切、重新调色或接受有损再编码，就能优化存储占用。
但这是一个存储层收益，不一定要求终端浏览器直接解码 JXL。平台完全可以采用分层方案：
- 原始资产或归档层使用 JXL；
- 图片服务根据客户端能力生成 WebP、JPEG 或其他已部署格式；
- 浏览器只接收当前产品已经验证过的格式；
- 当 JXL 的客户端覆盖率足够高时，再把它加入交付层。
这种架构把“是否采用 JXL”和“是否要求所有用户代理支持 JXL”拆成两个决定。前者可以由存储成本推动，后者则必须考虑整个 Web 的兼容性成本。
JXL 也并非没有风险。无损回转是否成立、元数据是否完整保留、解码时的内存峰值，以及工具链版本能否稳定复现，都需要用真实资产验证，而不能只看格式说明。
可以这样做一次可回滚的实验
如果已经安装提供 cjxl 和 djxl 的 libjxl 命令行工具，可以先挑选一张非敏感 JPEG 测试。下面的脚本会编码为 JXL、恢复 JPEG，并比较恢复结果是否逐字节一致。
不同工具版本的参数可能变化，运行前请先执行 cjxl --help，确认支持 --lossless_jpeg=1。将脚本保存为 test-jxl.sh，然后运行 bash test-jxl.sh sample.jpg。
#!/usr/bin/env bash
set -eu
input="${1:-sample.jpg}"
jxl="${input%.*}.jxl"
restored="${input%.*}.restored.jpg"
command -v cjxl >/dev/null || {
echo "缺少 cjxl，请先安装 libjxl 命令行工具" >&2
exit 1
}
command -v djxl >/dev/null || {
echo "缺少 djxl，请先安装 libjxl 命令行工具" >&2
exit 1
}
cjxl "$input" "$jxl" --lossless_jpeg=1
djxl "$jxl" "$restored"
if cmp -s "$input" "$restored"; then
echo "OK：恢复后的 JPEG 与输入文件逐字节一致"
else
echo "FAIL：恢复文件不同，请勿用于生产归档" >&2
exit 2
fi
wc -c "$input" "$jxl" "$restored"
单张图片的结果没有代表性。实际评估至少应覆盖相机照片、经过多次编辑的 JPEG、带 ICC 配置的图片、渐进式 JPEG、大尺寸图片和异常元数据。除了压缩率，还要记录编码时间、解码时间、峰值内存以及失败比例。
如果只是想在网页上进行小范围实验，不要让 JXL 成为唯一资源。可以通过 <picture> 提供逐级回退：
<picture>
<source srcset="/images/hero.jxl" type="image/jxl">
<source srcset="/images/hero.webp" type="image/webp">
<img
src="/images/hero.jpg"
width="1280"
height="720"
alt="产品控制台截图"
loading="lazy">
</picture>
服务器还需要为 .jxl 返回正确的媒体类型。以 Nginx 为例，可以这样补充映射：
types {
image/jpeg jpg jpeg;
image/webp webp;
image/jxl jxl;
}
这类实验必须保留 JPEG 或 WebP 回退，并通过真实用户监控确认图片加载成功。不要只在开发者自己的浏览器上测试，也不要仅依赖 User-Agent 字符串判断能力。
什么时候值得采用
是否部署 JXL，可以拆成两张清单。
适合先用于内部存储或转换管线：
- JPEG 资产规模足够大，存储成本真实可见；
- 可以验证并持续测试无损恢复；
- 图片服务本来就会动态生成交付格式；
- 团队能够维护额外的编码器和解码器；
- 原始文件仍有独立备份，迁移可以回滚。
不适合直接作为网站唯一格式：
- 无法控制访问者使用的浏览器和应用内 WebView；
- 没有回退资源或图片转换服务；
- 缓存键没有正确区分响应格式；
- 省下的流量不足以覆盖运维和测试成本；
- 团队把“编码成功”等同于“所有客户端都能可靠显示”。
JPEG XL 的技术价值与浏览器是否应该内置它，是两个不同问题。它可以是很好的归档格式、转换中间层，甚至是未来的交付格式，同时仍不足以证明今天的每个浏览器都应该永久承担它的实现成本。更稳妥的路线不是在格式战争中选边，而是先用真实资产测量收益，把 JXL 放进可回滚的管线，并始终为 Web 交付保留兼容路径。