2026年10月，Chrome 150正式落地了一项酝酿已久的Web平台能力------乱序HTML流（Out-of-Order HTML Streaming） 。这是一项让浏览器在页面加载过程中动态填充占位符的技术，Safari和Firefox也已明确表示将跟进支持。
更关键的是：这项能力过去十几年一直是React、Next.js等JavaScript框架的"专属特权"，如今它被内化到了浏览器引擎本身。你不再需要引入任何框架，纯HTML就能实现流式渲染。
一、问题：HTML天生是"线性"的
Web的核心矛盾之一，藏在HTML的交付方式里。
HTML从诞生之日起就是从上到下顺序交付 的。浏览器解析HTML的方式是线性的：读到<head>就处理head，读到<body>就渲染body，读到<script>就执行脚本。
但现代Web应用的内容生成顺序，往往和展示顺序不一致。
比如一个电商列表页：商品卡片的数据从数据库查询很快，但用户评价区域需要调用外部API、加载较慢。传统方案要么等所有数据都就绪再返回整个页面（用户看着白屏等），要么用JavaScript框架异步加载组件（引入框架依赖和运行时开销）。
React Server Components和Next.js的Streaming解决了这个问题，但它们的方式是在框架层面实现流式渲染。你使用它们的能力，就必须接受它们的运行时、它们的构建工具、它们的抽象模型。
2026年，这个能力从框架层下沉到了平台层。
二、乱序HTML流是什么？用两个标签就能实现
乱序HTML流的核心思路极其简洁：让浏览器在解析HTML时，可以先跳过暂时无法生成的内容，等数据就绪后再"回填"到正确的位置。
它依赖两个核心原语：<?marker>处理指令和带for属性的<template>元素。
最基本的用法
html
<ul id="results">
<?marker name="results"> Loading... <?end>
</ul>
<!-- 稍后在HTTP响应中流式传输 -->
<template for="results">
<li>Result One</li>
<?marker name="results">
</template>浏览器看到<?marker name="results">时不会立即做任何事 ------它只是记下这个位置。当服务器稍后流式传输到<template for="results">时，HTML解析器会匹配这个标识符，移除占位符和回退内容，将模板内容插入到那个DOM位置。
支持多次更新
模板中还可以包含新的<?marker>，实现渐进式多次更新：
html
<ul id="results">
<?start name="results"> Loading... <?end>
</ul>
<!-- 第一次更新 -->
<template for="results">
<li>Result One</li>
<?marker name="results">
</template>
<!-- 第二次更新 -->
<template for="results">
<li>Result Two</li>
<?marker name="results">
</template>每次更新都会替换掉上一个占位符，并在末尾留下新的占位符，等待下一次流式数据到达。解析并处理完所有模板后，最终得到完整的列表HTML。
安全边界
为了防止跨组件注入攻击（比如文档中其他位置的不受信任标记劫持敏感表单），<?marker>只能修补位于其直接父元素内的处理指令 。如果某个<template>被放置在<body>标签之下，它将获得全局文档作用域，延迟更新可以作用于文档中任何位置。
三、JavaScript API：不只是声明式
声明式标记解决了"服务端流式交付"的问题。但如果你需要在客户端动态插入HTML呢？
乱序HTML流方案定义了一套统一的DOM插入方法矩阵：
静态方法 ：setHTML、replaceWithHTML、beforeHTML、prependHTML、appendHTML、afterHTML
流式方法 ：streamHTML、streamAppendHTML等，以及对应的*Unsafe变体
Fetch API补充 ：response.textStream()
例如，调用streamHTMLUnsafe()会返回一个WritableStream，将传入的块数据增量地传输到内部的HTML片段解析器中。
这意味着你可以在不引入任何框架的情况下，实现"边下载边渲染"的流式效果。
四、浏览器支持与polyfill
Chrome和Edge 150 已经正式推出声明式标记功能。textStream()功能则随Chrome 151推出。配套的JavaScript DOM流式处理方法则继续通过单独的标准化流程推进。
WebKit已经表明了支持该特性的积极立场，Mozilla也已经释放出接纳该方案的积极意向。
如果你现在就想在生产中使用，Chrome团队发布了 template-for-polyfill ，已经发布在npm上，可以在尚未原生支持该功能的浏览器中提前使用。还有一个叫partial-html的包，在polyfill基础上做了进一步封装，支持在React的useEffect中安装，以便在水合完成后开始DOM修补。
五、它替代了什么？------从BigPipe到浏览器原生
乱序HTML流并不是一个全新的概念。
2009年，Facebook的BigPipe首次提出了"边生成边渲染"的思路------将页面拆分成多个"pagelet"，每个pagelet独立渲染并流式传输到浏览器。
2019年，React Suspense 和Next.js Streaming 把这种思路带入了主流前端框架。你可以在React组件里使用<Suspense>包裹异步内容，框架负责在数据就绪时"补上"渲染结果。
但这些方案的共同问题是：它们是框架层面的实现，而不是平台层面的能力。
你使用React的Streaming，就必须接受React的运行时、React的构建工具、React的抽象模型。你使用Next.js的Streaming，就必须部署在支持Next.js的平台上。
乱序HTML流把这件事标准化到了浏览器引擎层面。任何服务端框架------无论是Next.js、Nuxt、SvelteKit、Remix，还是你自己手写的Node.js服务------都可以通过输出特定的HTML标记，让浏览器原生地执行流式渲染。
框架不再需要"发明"自己的流式协议。浏览器已经提供了标准答案。
六、实际应用场景
场景一：SSR应用的分阶段渲染
你的首页有一个"热门推荐"模块需要调用推荐算法，耗时较长。传统SSR要么等算法返回再渲染整个页面，要么在客户端用JavaScript异步加载。
用乱序HTML流，你可以先交付页面骨架，推荐模块的位置放一个<?marker>。当推荐算法返回后，服务器继续流式传输<template for="recommendations">，浏览器自动填充。
用户看到页面的时间大幅提前，而推荐内容在就绪后"无缝出现"。
场景二：AI聊天界面的流式输出
AI聊天应用需要"边生成边显示"。过去这依赖WebSocket或SSE配合JavaScript框架的状态管理。
用乱序HTML流，服务器可以直接把AI生成的每个token作为HTML片段流式传输到浏览器。你不需要在前端维护一个复杂的消息状态机，浏览器自己就会把内容"拼"到正确的位置。
场景三：渐进增强的传统网站
你有一个传统的服务端渲染网站，不想引入任何JavaScript框架，但又想实现"首屏快速可见、次要内容延迟加载"。
乱序HTML流是零JavaScript的解决方案 。你只需要在模板中放置<?marker>，在服务器端按需流式传输<template>，浏览器负责一切。
七、这对前端开发者意味着什么？
1. 流式渲染从"框架能力"变成"平台能力"
过去选择Next.js或Remix，一部分原因就是它们提供了流式SSR。现在浏览器原生支持了这项能力，框架在这方面的差异化优势正在被抹平。
2. 服务端框架的"协议层"正在标准化
React有自己的Streaming协议，Vue有Nuxt的协议，SvelteKit有自己的协议。乱序HTML流提供了一个统一的平台层协议。未来框架可能只需要在底层输出标准标记，而不再需要各自发明轮子。
3. 零JavaScript的流式体验成为可能
对于内容型网站、电商列表页、博客等场景，不需要任何客户端JavaScript就能实现"渐进式渲染" 。这对性能敏感的项目来说是一个重要的简化。
4. 对AI Agent更加友好
当AI Agent需要读取一个正在流式渲染的页面时，标准的HTML标记比框架特定的JavaScript协议更容易解析。平台层的标准，对Agent来说比框架层的抽象更可预测。
写在最后
2026年10月，乱序HTML流正式进入Chrome和Edge 150。Safari和Firefox已经表态跟进。
这项技术由Facebook的BigPipe在2009年首创，经由React和Next.js在2019年带入主流，最终在2026年被内化到浏览器引擎本身。
前端流式渲染的"框架特权"被终结了。 你不再需要选择一个特定的框架来获得流式渲染能力。浏览器已经提供了标准答案。
参考链接：