News Hacker｜极客洞察

🎯 讨论背景

此讨论源于 Chromium/Chrome 团队计划在浏览器中弃用或移除对 XSLT 的原生支持，触发了对安全、兼容性与网络开放性的争论。xslt.rip 是一个用 XSLT 本身制作的讽刺/悼念式网页（通过 检测浏览器支持并展示不同内容），用来吸引对这一变动的关注。Chromium 给出的技术理由集中在底层 C 实现（如 libxslt、libxml2）存在长期维护与内存安全问题并出现 CVE，因此有方案要以 memory-safe 实现替代或直接移除；反对者则提出 JS/WASM polyfill、扩展沙箱化或 Rust 重写等替代路线。讨论把影响面扩展到 RSS/Atom 在浏览器的可用性、政府与企业的既有 XML 工作流、以及当主导厂商停止支持某功能时对去中心化网络的潜在冲击。

📌 讨论焦点

安全与维护驱动的移除

反对保留 XSLT 的声音把焦点放在底层实现的维护和内存安全上：Chromium 依赖的 libxslt（以及关联的 libxml2）被指出长期维护不足并含有多项内存安全漏洞，研究者在公开演讲和 CVE 报告中展示了利用面。Chrome 团队以这些安全问题为理由提出弃用，并计划用 memory-safe 的替代或直接移除相关原生支持。批评者并不否认漏洞存在，但质疑直接移除而不先采用替代方案（如沙箱化的 WASM/extension 或采用 Rust 重写）的必要性，指出已有 polyfill、扩展和 Rust 实现可作为过渡或修复路径。讨论中也有对 Chromium 在拒绝打包 polyfill 或替代实现时理由透明度的质疑，认为官方论述有时被认为过于笼统或误导。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]

客户端 XSLT 的实际用途与影响（RSS／PWA／政府／企业）

大量评论列举了 XSLT 在真实生态中的具体用例：通过 把 RSS/Atom 订阅源在浏览器端直接呈现为可读页面、在静态托管环境下用一个 XML 文件同时承载数据与表现、以及在一些政府站点、企业系统和医疗电子病历中作为文档渲染或转换工具。支持者强调客户端 XSLT 对无需服务器端逻辑的个人静态站点或离线 PWA 非常便利，服务器端替代会增加复杂度、缓存和部署成本，且不是所有用户会为浏览器安装扩展或 polyfill。反对者则指出许多生产场景本就把 XSLT 放在服务器端运行，受影响的前端站点数量可能比抗议者声称的要少，影响范围在不同案例间差异显著。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]

替代方案与技术实现（polyfill、WASM、Rust、服务器端）

讨论中提出多种替代路径并权衡其利弊：服务器端转换可以保证浏览器兼容性但不适合完全静态或离线场景；已有的 JS/WASM polyfill（例如 mfreed7/xslt_polyfill）和 Saxon-JS 能恢复客户端功能，但会增加数 MB 依赖并非零成本方案。另有建议把现有 C 实现沙箱化打包为浏览器扩展（类似 PDF.js 的处理方式）、或采用 Rust 重写（如 xrust/markup-rs）以解决内存安全问题，但这些都需要工程与维护投入。还有一些更轻量的折中方案被提出：通过 HTTP Link/Accept 头提供样式、在服务器返回已转换的 HTML，或鼓励浏览器厂商内置或捆绑受维护的实现以平衡兼容与安全。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]

情绪、讽刺與集中化担忧

xslt.rip 本身带有强烈讽刺与怀旧色彩：网站用 XSLT/ 本身演示了功能检测，并采用复古设计引发“怀旧死而复生”的讨论。不少人把事件上升为对 Chromium/Google 市场主导地位的担忧，认为当市占巨头停止在浏览器内支持某特性时，等同于对该特性下“死刑判决”，这引出关于开放网络与去中心化（如 RSS、政府公开数据）的政治语境。也有评论认为站点夸张成分多、可能难以说服决策者或被视为戏谑，但作为唤起关注与讨论的手段仍被不少人认可。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]

对 XSLT 语言与生态的评价（晦涩的工具 vs 文档导向的价值）

评论里对 XSLT 自身有截然不同的工程评价：一部分人怀念 XML+XSLT 曾提供的文档导向、可组合的标准化生态，认为拆散重建成一堆不兼容的库是人才与资源的浪费；另一部分人则直言 XSLT 语法古怪、难以掌握，认为现代堆栈（JSON + JavaScript）在可用性和社区支持上更胜一筹。讨论还涉及规范复杂度与实现质量差异：XML 生态规范厚重但实现通常“严谨”，而 JSON 生态虽简单但在边界行为上衍生出大量不一致。总体来看，争论既有技术层面的权衡，也包含对开发者偏好与历史选择的价值判断。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

📚 术语解释

XSLT: XSLT（XSL Transformations）：W3C 标准的样式表/转换语言，用来把 XML 文档转换为 HTML、另一个 XML 或纯文本；浏览器历史上支持通过 或 JavaScript 的 XSLTProcessor 在客户端执行。

libxslt: libxslt：用 C 语言实现的常见 XSLT 引擎，历史上被部分浏览器（尤其 WebKit 衍生）或工具采用；讨论中被指出长期维护薄弱并存在内存安全问题，是 Chromium 弃用决策的直接技术原因之一。

libxml2: libxml2：一个用 C 语言编写的广泛使用的 XML 解析/序列化库，Chromium 依赖其做 XML 处理；近期报告的若干安全问题促使 Chromium 考虑以 memory-safe（例如 Rust）实现替换。

（processing instruction）: ：XML 内的处理指令，用来指向 XSLT 样式表，使浏览器或处理器能在客户端将同一 XML 文件转换为可读页面，是静态托管场景下一个关键便捷点。

XSLTProcessor: XSLTProcessor：浏览器端的 JavaScript API，用以在运行时以脚本方式对 XML 执行 XSLT 转换，部分网站以此实现动态渲染或离线功能。

polyfill: polyfill：用 JavaScript/WASM 在页面中实现或模拟浏览器未内建的功能的库（本讨论的例子如 mfreed7/xslt_polyfill），用于在原生不支持时恢复行为但会引入体积与维护成本。

WASM（WebAssembly）: WASM（WebAssembly）：一种浏览器中运行近原生速度编译代码的二进制格式，可把 C/C++/Rust 等代码编译为沙箱内执行，常被提为把现有 XSLT 引擎移植到客户端的方案。

RSS / Atom: RSS/Atom：基于 XML 的订阅/聚合格式，许多站点通过 XSLT 在浏览器端直接渲染订阅源为可读页面，浏览器对 XSLT 支持的变化会直接影响这些静态订阅页的可读性。