Chrome 150支持乱序HTML流，Safari与Firefox将跟进

乱序 HTML 流允许页面在完整加载前就展示内容并响应交互。浏览器会根据声明式 HTML 或 JavaScript API 接收的片段，实时替换页面中的占位区域。Chrome 150 已加入相关声明式能力，Safari 和 Firefox 也表达了跟进意向。

方案通过为 template 元素增加 for 属性来声明插入点，既可以指定单个目标，也能包裹“Loading profile...”等临时回退内容。服务器随后可流式返回与目标匹配的 script type="text/html" data-for="id" 内容，解析器会找到对应标识，移除占位标记及其中的回退节点，再把新 HTML 插入目标 DOM。模板还可携带处理指令，以支持多次增量更新。例如，results 列表先显示 Loading，后续两个模板分别写入 Result One 和 Result Two，最终列表中会保留这两项以及用于继续更新的标记。

为降低跨组件注入风险，处理指令默认只能影响其直接父元素范围内的同级节点及子节点，避免文档其他位置的不可信标记修改敏感表单或导航目标。如果模板位于 body 之下，则可获得全局文档作用域，使延迟更新能够作用于 body 内部或嵌套容器。

该提案也在扩展客户端脚本能力，统一定义 setHTML、replaceWithHTML、beforeHTML、prependHTML、appendHTML、afterHTML，以及 streamHTML、streamAppendHTML 等流式方法和 Unsafe 变体。以 streamHTMLUnsafe() 为例，它会返回 WritableStream，把收到的数据块持续交给内部 HTML 片段解析器。Fetch API 则提供 response.textStream()，开发者可以将接口返回的 UTF-8 文本直接管道传入目标容器，并通过 runScripts: false 控制脚本执行。

这种做法把过去由框架承担的乱序交付和渐进渲染下沉到浏览器。相关思路最早由 Facebook 的 BigPipe 于 2009 年提出，后来在 React 的 Suspense 流式传输和 Next.js 等框架中普及，核心都是避免耗时区域阻塞整页加载。相关声明式标记已纳入 WHATWG HTML Living Standard，Chrome 和 Edge 150 已提供初步支持，textStream() 随 151 版本推出；JavaScript DOM 流式方法仍在独立标准化，WebKit 与 Mozilla 均释放了积极信号。