流式 HTML 更新：告别 innerHTML 的全量阻塞时代

背景：现有 HTML 更新方式的根本缺陷

过去，前端动态更新页面内容主要依赖 innerHTML 或 insertAdjacentHTML。这些 API 的工作模式是“全量替换”：必须拿到完整的 HTML 字符串，才能一次性写入 DOM。

这带来了一个本质矛盾。HTML 的核心优势之一就是流式传输——浏览器可以一边接收字节一边渲染内容，用户感知到的加载速度因此大幅提升。但现有的 DOM 更新 API 恰恰破坏了这一优势：当你用 innerHTML 更新一个区域时，必须先把所有内容下载完毕，再一次性塞进页面。

虽然开发者可以用 document.write 绕过这个限制，但 document.write 在动态场景下会清空整个文档，早已被标记为过时且危险的方法

新方案：静态 API + 流式 API 的组合

Chrome 团队为 setHTML 和 setHTMLUnsafe 扩展了一套全新的方法和流式版本。核心设计思路是：每个操作都有静态和流式两个版本，命名规则统一，语义清晰。

静态版本接受一个 HTML 字符串，用法直观：

const contentElement = document.querySelector('#content-to-update');
contentElement.setHTML('<p>这是一段新内容</p>');

流式版本的用法则体现了这套 API 的核心价值。它返回一个 Writer，你可以按需逐段写入内容：

const writer = contentElement.streamHTML().getWriter();

// 逐条更新，无需等待完整数据
for (let i = 0; i < 10; i++) {
  await writer.write(`<p>第 ${i + 1} 条消息</p>`);
  await new Promise(resolve => setTimeout(resolve, 1000));
}

writer.close();

更实用的场景是与 fetch 结合，直接将服务端的流式响应管道到 DOM：

const response = await fetch('/api/stream-content');
response.body
  .pipeThrough(new TextDecoderStream())
  .pipeTo(contentElement.streamHTML());

Chrome 还专门添加了一个便捷方法 textStream()，省去中间的 TextDecoderStream 步骤：

response.textStream().pipeTo(contentElement.streamHTML());

安全设计：默认过滤，可选“不安全”

这套 API 默认内置了 HTML Sanitizer，会过滤掉潜在的 XSS 风险内容。如果你需要自定义过滤规则，可以通过 options 传入 Sanitizer 配置：

const basicSanitizer = new Sanitizer({ 
  elements: ['em', 'i', 'b', 'strong'] 
});
contentElement.setHTML(rawHTML, { sanitizer: basicSanitizer });

每个 API 都有对应的 Unsafe 版本（如 streamHTMLUnsafe），默认关闭过滤，适用于可信内容源且需要执行 <script> 的场景。

浏览器支持与标准化状态

目前该功能在 Chrome 148 中通过 chrome://flags/#enable-experimental-web-platform-features 启用，预计将在 Chrome 155 正式发布。Microsoft Edge 154 的发布说明中未提及此特性，这意味着它目前仍处于 Chrome 主导的早期阶段。

标准化讨论中的核心分歧集中在 Unsafe 方法上：是否应该让开发者有能力执行流式注入的 <script> 标签，以及如何与 Trusted Types 规范协同工作。

这对开发者意味着什么

这套 API 最直接的价值场景是AI 生成内容的流式渲染和实时数据推送界面。当服务端逐 token 生成响应时，前端可以同步逐段渲染 HTML，而不是等完整响应返回后再一次性替换整个区域。

对于依赖 innerHTML 做局部更新的现有代码，短期内无需迁移——静态版本的 setHTML 提供了更安全、语义更清晰的替代选择，可以作为渐进式改进的第一步。流式版本则在需要时才引入。