1. 为什么流式渲染不是“锦上添花”，而是 AI 应用的体验底线
最近在折腾 AI 应用的输出链路时，发现大多数人把“流式渲染”想简单了。很多人以为只要后端把 token 一个接一个吐出来，前端用innerHTML拼一下就行。但真实情况是：模型输出的是一大段 Markdown 文本流，里面有标题、列表、表格、代码块、嵌套引用，甚至还有半截的 JSON 结构。如果前端不做任何处理，直接把半成品字符串塞进页面，用户看到的就是格式错乱、闪烁抖动、代码块高亮失效的灾难现场。
流式渲染的第一个价值是抢时间。同样的内容，等全部生成完再一次性渲染，用户可能盯着空白屏幕等 3 到 5 秒；而流式渲染可以把首屏可读内容的时间压缩到几百毫秒。尤其在企业级应用里，AI 回答动辄上千字，等待时间越长，用户流失率越高。更重要的是，流式渲染给用户提供了一种“过程可控感”——看到内容在逐步生成、逐步完整，用户会更容易理解 AI 的推理路径，也更愿意接受错误和修正。这不是玄学，是交互心理学里“进度可视化”的实际应用。
第二个价值藏在技术层面。流式渲染要求前端具备“增量解析 + 局部更新”的能力，这套能力天然适合生成式 UI 的落地。AI 不只是输出纯文本，它还能输出结构化组件、操作按钮、数据面板。当你的渲染管线已经支持“边流边渲染”，把 Markdown 里的某个扩展块映射成 React/Vue 组件，就成了顺理成章的事。所谓“生成式 UI”，本质上就是把 AI 的输出从“一段文字”升级为“一组可交互的界面元素”，而流式渲染是它的地基。
这篇文章适合谁看？如果你在做 AI 对话产品、智能助手、内容生成工具，或者正在研究 LLM 输出的前端呈现方案，这篇文章可以直接抄作业。我会从数据协议、增量解析、渲染管线、组件映射、故障排查五个维度，把整个链路拆开讲清楚。
2. 数据协议与流式传输：先解决“怎么收”的问题
2.1 为什么选 SSE 而不是 WebSocket
流式渲染的第一步不是渲染，而是“怎么把数据从服务端接到前端”。目前主流方案有两个：SSE（Server-Sent Events）和 WebSocket。我一向优先选 SSE，原因很简单——AI 生成场景是单向的、文本密集的、且需要自动重连。SSE 基于 HTTP 长连接，天然支持断线重连和事件 ID 追踪，而 WebSocket 是双向全双工协议，在这个场景里属于杀鸡用牛刀，还平白增加心跳维护和消息序列化的复杂度。
实际项目里，模型服务返回的数据流通常长这样：
event: token data: {"content":"你好"} event: token data: {"content":"，今天"} event: done data: {}SSE 的消息格式很短，解析成本几乎为零。前端用原生的EventSource或者自己封装一个 fetch + ReadableStream，就能逐条读取。关键细节是：每条data里尽可能减少嵌套层级，不要让 token 在 JSON 里包三层再出来。我见过有人把整个大对象序列化后塞进 data，前端拿到还要做一次深解析，白白浪费主线程时间。好的设计是服务端先把 token 或片段内容抽出，用{type, delta}这样的扁平结构下发。前端要解码的东西越少，流式渲染的帧率就越稳。
2.2 处理 UTF-8 截断：中文乱码的根源
流式传输的一个经典坑是：网络包在传输过程中会被拆成任意大小的 chunk，而 UTF-8 编码下，一个中文字符占用 3 个字节。如果服务端在字节边界处把内容切断，前端拿到的那个 chunk 就会以“半个字符”结尾，直接解析就会出现乱码或者替换字符 �。
这个问题的解法在服务端，不在前端。服务端不要把字符串原样切割，而是用Buffer或者TextEncoder先把字符串编码成字节序列，等到积累了完整字符后再发送。实操中更简单的方法是：不按字节切，而是按“增量 token”切。模型每输出一个 token，服务端直接把它追加到发送缓冲区，并且判断缓冲区结尾是不是一个完整的 UTF-8 字符序列。如果结尾字节处于不完整状态，就暂时留到下一条再发。
前端也不能完全被动接收。稳妥的做法是用TextDecoder的stream: true模式来解码字节流，而不是积累字符串后JSON.parse。TextDecoder专门处理跨 chunk 的字符边界，实测下来基本不会出现乱码。哪怕服务端偶尔切断了字节，前端也能正确拼接。
2.3 内容缓冲策略：按 token 收还是按时间收
流式传输还有一个调优参数：多久把缓冲区里的内容推送给渲染层。推得太频繁，比如每个 token 都更新一次 DOM，会造成浏览器频繁重排，CPU 占用飙升，用户体验反而变差。推得太慢，又丧失流式渲染的意义。
我的经验值是 120 到 200 毫秒批量推送一次。用requestAnimationFrame兜底，确保每次刷新都跟浏览器的渲染帧对齐。具体逻辑是：
let buffer = []; let timer = null; function onChunk(chunk) { buffer.push(chunk); if (timer === null) { timer = setTimeout(flush, 150); } } function flush() { render(buffer.join('')); buffer = []; timer = null; }这个基于时间窗口的合并策略，比“每个 token 都刷新”的 CPU 占用能降低一半以上，而用户感知到的延迟几乎没有差别。别小看这个细节，当并发会话多、页面里还有编辑器和高亮组件时，性能差距会非常明显。
3. 从字节流到结构化文档：增量解析的设计思路
3.1 增量解析器的核心逻辑：状态机驱动
拿到文本流之后，最忌讳的做法是“每次收到新片段就把全文重新解析一遍”。假设用户输入了 1000 个字，第 999 个字到达时，你还要重新解析前面 998 个字，复杂度是 O(n²)，页面迟早卡死。真正的解法是增量解析：把解析器设计成状态机，每次只消费新增的那段文本，然后更新解析状态和输出结构。
Markdown 的语法天然适合状态机建模。整篇文档可以抽象成一个“块级元素栈”，栈顶是当前正在处理的块（段落、列表、引用、代码块、表格等）。每来一个新片段，就把片段逐字符/逐行送给状态机，状态机根据当前栈顶状态决定是继续累积内容还是切换到新块。
这里有一个核心的数据结构：
class ParserState { stack = []; // 块级元素栈 buffer = ''; // 当前未完成的文本片段 mode = 'normal'; // normal | code | table | list codeFence = null; // 代码块围栏语言 }比如遇到```javascript时，状态机把 mode 切换成 code，然后接下来的所有内容都进入代码块分支，直到遇见结束围栏。遇到| 列1 | 列2 |时，状态机进入 table 模式，开始解析表头和分隔符行。这种栈式状态机的思路，跟编译器做语法分析是一个套路，只是 Markdown 的语法约束比编程语言宽松得多。
3.2 处理未闭合元素：半截代码块和表格
增量解析最头疼的问题是语法结构不完整。模型生成| 名称 | 数 | 量 |之后，可能停顿 500 毫秒才继续输出下一行；生成```python之后，可能要等一秒钟才会出现第一行代码。如果渲染层拿到半截语法就按完整结构渲染，轻则内容错位，重则代码块直接盖住后续所有内容。
我的处理策略是“分层渲染 + 占位保留”。解析器遇到未闭合的块，比如没有结束围栏的代码块，先把当前内容渲染成代码块样式，但给一个底部过渡区；表格只解析出表头和前几行，后续行到达时再逐行追加。渲染层绝不因为“结构不完全”就放弃渲染已拿到的内容——相反，流式渲染的美妙之处就在于“先给你看到的一部分，再补全剩余部分”。
关键细节是记录每个块的“打开位置”。当后续片段到达时，如果发现某个块已经闭合，就直接将新内容作为相邻块追加；如果块未闭合，就把新内容追加到这个块内部。比如表格块的打开位置在第 5 行，后续来了第 6、7 行，也属于表格块，追加进去即可。这个按位置归属的逻辑简单可靠，不用每次重建整棵文档树。
3.3 容错与降级：解析出错时怎么办
增量解析不可能 100% 完美。模型可能输出不规范的 Markdown，比如#和文字之间没加空格，或者嵌套列表缩进混乱。解析器要设计容错机制，我的标准是“不崩溃、不卡死、不吞内容”。遇到解析不了的结构，就把当前行当作普通段落处理，等到上下文明确后再纠正。
具体做法是给解析器设置最大回溯深度。默认 20 层，超过这个深度就强制将当前块弹出，作为独立块结束。这可以防止极度复杂的嵌套列表把栈撑爆。同时，解析器维护一个“宽容开关”：当遇到同一个块重入超过 5 次（比如> > > > > >这样无限嵌套引用），直接降级为普通文本，不再做嵌套结构。
这里有个经验：别再等解析器彻底稳定了才渲染。流式渲染的本质是“带着毛边往前跑”，你要做的是让毛边尽量不影响用户观感，而不是追求解析器完美无缺。很多人在这一步过度设计，导致代码复杂度爆炸，最后反而因为 bug 太多而更不稳定。
4. 渲染管线实战：从解析结果到 UI 增量更新
4.1 构建文档树与节点 ID 分配
解析器输出的不能是纯 Markdown 字符串，而是一棵“文档树”。每个块级元素占一个节点，节点上有稳定的唯一 ID。这个 ID 是后续增量更新的锚点。比如一个二级标题的节点 ID 是h2-3，它对应文档里的第三个二级标题；一个代码块的节点 ID 是code-2。
为什么需要节点 ID？因为流式渲染时，前端要在“旧节点”的基础上做局部更新，而不是整树重建。没有 ID 的话，diff 算法无法判断某个节点是新增的还是被修改的，只能靠粗暴的“删除全部，重建全部”。有了 ID，就可以做到“这个表格只更新最后一行”“那个代码块只追加两行代码”，更新范围精确到节点级。
节点 ID 的生成规则要保证在同一棵文档树下唯一，且不受后续内容插入影响。常见做法是给每个块打一个递增序号，再结合类型前缀。注意不能只依赖行号，因为行号会随着前面内容变多而偏移。我踩过这个坑：行号作为 ID，前面插入一段文字后，后面所有节点的 ID 全变了，diff 直接失效，页面就整体闪烁。
4.2 增量 diff 与 patch：不是虚拟 DOM 的专利
很多人一听到“增量更新”就想到虚拟 DOM。实际上，Markdown 文档树的增量更新比组件树的 diff 简单得多，完全不需要跑完整的前端框架 diff。因为文档树的结构变化是有规律可循的：绝大多数情况下是“追加”，少数情况是“在中间插入”，几乎不会出现“删除”和“移动”。回想一下模型输出过程——它只会在流式过程中追加内容，很少回头修改前面已经生成的文本。
基于这个规律，我设计了一套精简的 patch 协议。服务端或前端解析器每产出一批新节点，就生成一组 patch 指令：
[ { op: "append", parentId: "doc", node: {...} }, { op: "updateText", nodeId: "h2-3", text: "新增的标题内容" }, { op: "appendChild", parentId: "table-1", node: {...} } ]渲染层拿到 patch 后，直接按指令操作 DOM。整个过程不需要对比新旧两棵树的差异，省掉了最耗时的遍历环节。实测在 3000 字的长文档持续流式输出时，一次 patch 的平均计算时间可以控制在 1ms 以内。虚拟 DOM 在这种场景下完全没必要，反而增加内存开销。
4.3 代码块与表格渲染的专项优化
代码块和表格是流式渲染里最容易翻车的两个元素。
代码块的难点在于高亮。高亮算法对“半成品代码”极不友好——一行写了一半的const foo = 'bar，语法分析器大概率会挂掉或产生奇怪的结果。我的解法是“延迟高亮 + 按行增量”。先把代码块内容按行累积到内存里，当行数超过 3 行或者代码块闭合时，才对整块代码做一次完整高亮。如果是 200 行的大代码块，则按每 30 行一个分块进行增量高亮，避免一次性处理太多文本导致卡顿。
表格的难点在于列宽和结构对齐。流式过程中，表格可能只有一半列，或者表头还没闭合。我的策略是：先按“当前完整行”渲染，列宽根据已到达的行动态计算，但限制最大列数（超过 6 列就改用横向滚动容器）。当后续行到达时，如果新行的列数和当前 DOM 结构不一致，就做一个平滑的列宽过渡动画，至少让用户能感知到“表格正在被补全”。
4.4 布局抖动抑制与滚动锚定
流式渲染最容易被吐槽的问题是“页面乱跳”。用户正在读前面的内容，后面新内容不断插进来，把视口往下顶，阅读进度一下就丢了。这个问题的缓解手段，业内标准做法是“滚动锚定”（scroll anchoring），浏览器原生支持overflow-anchor属性，但实际效果并不完全可控。
我通常再叠加一个“局部锚定”策略。渲染层记录当前用户可见区域的第一个块节点 ID，当新 patch 到达时，只更新该节点之前的内容，不改变页面滚动位置。只有用户主动滚动到文档尾部时，才把新内容“接到”当前视口的后面。这个策略的代码量不大，但用户体验的提升非常明显。没有它，用户可能每 3 秒就被迫重新找一次阅读位置，再好的内容也会被交互问题毁掉。
滚动锚定之外，还要抑制布局抖动。主要方法是用 CSScontain属性给每个块设置独立的布局上下文，避免一个块的高度变化引起整页重排。代码块容器用contain: layout style，表格容器用contain: content，实测能大幅降低 diff 更新时的 reflow 面积。
5. 从 Markdown 文本到生成式 UI：组件映射与动态渲染
5.1 生成式 UI 的本质：从陈述到操作
流式渲染解决的是“文本如何平滑呈现”，生成式 UI 解决的是“如何让 AI 直接生成可交互界面”。两者的关系是递进的：先把文本流稳定渲染出来，才有能力在文本流中嵌入结构化的组件声明。
生成式 UI 的核心思路是：AI 的响应不再只是一段 Markdown，而是包含特殊扩展块的“文档”。比如模型输出：
下面是本月的数据报表： ```component weather-widget { "city": "北京", "days": 5, "units": "metric" }前端渲染时，遇到component weather-widget这个代码块，不按普通代码渲染，而是找到对应的weather-widget组件，把 JSON 作为 props 传进去挂载。这样 AI 输出的就不只是“一段关于天气的文字”，而是“一个可以交互的天气面板”。
5.2 结构化输出协议：让模型按格式生成
要让模型输出这种组件声明，不能靠提示词里写一句“请输出组件”。你需要一套严格的结构化输出协议。实际项目中，我通常用 JSON Schema 来约束模型的输出格式。系统提示词里明确声明：当需要生成某个类型的组件时，必须输出指定格式的代码块，且 JSON 字段必须符合 Schema 定义。
这套协议的落地离不开工具调用（function calling）或结构化推理能力。简单说，让模型在规划阶段就决定哪些地方生成组件、哪些地方生成普通文本。中间状态可以用特殊标记包裹，比如用<<<COMPONENT:weather-widget>>>和<<<END_COMPONENT>>>这样的自定义标记。前端解析器只认这些扩展标记，解析到标记时从普通 Markdown 模式切换到组件模式，把标记之间的 JSON 传给组件管理器。
需要注意的是，组件声明和渲染的先后顺序问题。流式输出时，模型可能先输出组件的开头部分，比如<<<COMPONENT:weather-widget>>>，然后停顿一下，再输出 JSON 内容。前端在解析到开标记时，不能立刻挂载组件——数据还没到齐。稳妥的做法是：先渲染一个“组件占位符”，等闭合标记到达、JSON 完整后，再真正挂载组件。如果需要更早的反馈，可以在占位符上展示骨架屏或者“组件生成中”的提示。
5.3 组件沙箱与安全边界
AI 生成的组件意味着前端会执行任意组件的渲染逻辑。如果这个组件内部有用户输入或者来自模型的动态内容，必须考虑安全问题，尤其是 XSS 风险。Markdown 里允许富文本，组件 props 里也可能包含 HTML 片段，在渲染前必须过滤脚本标签和事件属性。
我的安全策略分三层。第一层是组件类型白名单：只有注册过的组件类型才允许挂载，未注册的类型一律渲染为普通代码块或警告框。第二层是 props 校验：组件挂载前，对 JSON props 做递归校验，确保不存在函数、对象原型链污染等危险类型。第三层是渲染隔离：组件默认放在 Shadow DOM 或独立的 iframe 中，样式和脚本都不与主文档共享，这样即使组件内部有异常，也不会波及整个页面。
组件渲染的临时态和最终态也要分开管理。流式过程中，组件可能反复收到更新。比如天气面板的 days 参数从 3 变成 5，前端不应每次重建整个组件，而是调用组件暴露的updateProps方法。这就要求自定义组件必须遵循统一的生命周期接口。我在实践中定义了三件套：create(props)、update(props)、destroy()，所有可生成式 UI 组件必须按这个接口实现。
6. 常见问题排查与实操教训
6.1 乱码、截断与半截字符串
症状：页面上出现�替换字符，或者 JSON 解析报错。
排查路径：
- 先在服务端打印原始字节流，确认是不是服务端切割了 UTF-8 序列。用
Buffer.isEncoding('utf8')检查，或者直接看末尾字节。 - 再看前端解码方式。确认使用的是
TextDecoder('utf-8', {stream: true})，而不是直接拼接后Buffer.from。 - 最后看数据传输层有没有额外编码转换。某些 HTTP 中间件会把
text/event-stream强制转成 ISO-8859-1，这种坑非常隐蔽。
经验总结：这个问题的根因九成在服务端切割逻辑，剩下的可能是网关或代理层动了编码。前端用TextDecoder已经是兜底方案，真正的修复必须发生在数据源头。
6.2 布局抖动和渲染闪烁
症状：页面内容渲染后突然跳位，或者元素先显示为纯文本，再变成格式化样式。
排查路径：
- 先检查是否每次接收新 token 都触发了整树重建。在 patch 链路上做一次 console.count，确认对同一节点是否执行了多次 replace。
- 再检查节点 ID 是否稳定。打印节点 ID 列表，对比两次更新之间的变化，如果大量 ID 变更，说明 ID 分配规则有问题。
- 最后检查 CSS contain 属性是否生效。用浏览器 Performance 面板看渲染的 reflow 面积，如果过大，说明布局隔离失败。
经验总结：我发现 90% 的闪烁问题不是渲染性能不够，而是 diff 逻辑出了偏差，导致节点被误删重建。先修 diff，再调性能，顺序不能反。
6.3 高亮失效和代码块抖动
症状：代码块流式过程中，高亮颜色突然丢失，或者整块代码闪白。
排查路径：
- 高亮是否被重复触发。同一段代码，如果解析器在未闭合时触发了一次高亮，闭合后又触发一次，两次的结果可能不一致，引起视觉抖动。
- 高亮库是否支持增量输入。很多高亮库会内部缓存状态，如果你传入半截代码，它会返回一个不稳定的结果。
- 代码块是否被多次重建。检查代码块节点的 key 是否稳定。
经验总结：代码块的高亮延迟到完全闭合之后再触发，是性价比最高的方案。如果必须流式高亮，就用独立的 worker 线程运行高亮逻辑，避免阻塞主线程。
6.4 内存泄漏与长会话卡顿
症状：AI 对话持续 20 分钟以上后，页面越来越卡。
排查路径：
- 用 Chrome 的 Memory 面板做两次快照，对比节点数量和监听器数量有没有明显增长。
- 组件挂载/销毁时，确认事件监听器有没有解绑。尤其是自定义组件的
update方法里注册的监听器，特别容易被遗漏。 - 检查文档树是否在无限增长。旧 token 的字符串如果一直被保留在文本节点里，即使不可见也不回收，内存会越积越高。
经验总结：长会话场景下，建议对超出视口范围的旧内容做“虚拟化”处理，把已经离开视口的文本节点移出 DOM，但保留节点 ID 和元数据。用户回滚查看时再用占位节点替换回来。这套方案在做 AI 知识库对话产品时非常重要，否则一个小时的会话就能让你页面崩掉。
6.5 断线重连与消息续传
症状：网络抖动导致连接断开，恢复后前端渲染的内容出现缺口。
排查路径：
- SSE 的
lastEventId有没有正确下发。断线重连时，服务端应该根据客户端上传的事件 ID，从断点处继续下发。 - 前端解析器能否接受“只补增量”的数据。如果解析器没有设计成可重入状态机，重连后的增量内容可能和已有内容冲突。
经验总结：服务端发送任务 ID，前端保存当前已解析位置。重连时，前端把receivedOffset传给服务端，服务端从偏移位置继续发送。这个实现复杂度比前端全量重放低得多，而且能保证渲染的连续性。
7. 性能调优和实测经验
流式渲染的性能调优，我在多个项目里反复打磨，总结出一套可复用的调优路径。当页面出现卡顿、CPU 持续高占用、移动端烫手等问题时，按这个顺序逐一排查，比盲目优化有效得多。
先明确性能瓶颈的三个维度：解析开销、渲染开销、浏览器 GC 压力。解析开销来自 Markdown 状态机对文本的逐行处理；渲染开销来自 DOM 更新和布局计算；GC 压力来自频繁创建和销毁临时对象。三者的优化策略完全不同，不能混为一谈。
解析层面的优化空间其实不大，因为 Markdown 解析本身是轻量操作。真正的大头在渲染。我的实测数据：5000 字文档加上 30 行代码块，全量渲染一次约耗时 80ms；而用增量 patch 方案，每次 token 到达只做追加操作，平均耗时 2ms 左右。这个差距在移动端更大，低端机型上可能从两百毫秒退化到卡顿。
GC 压力容易被忽略。我遇到过一个诡异的问题：内存曲线呈阶梯状上升，每到达一批 token 就涨一点，偶尔下降一点，但整体趋势在涨。排查后发现是解析器每次都会创建一个新的ParserState对象，旧的没有被及时回收。解决方式很简单：复用解析器实例，每次解析前重置内部状态字段，而不是新建对象。
代码块高亮是另一个 GC 大户。高亮库会把代码切分成 token 数组，每个 token 占一个对象，几百行代码会产生上万个对象。我的优化方案是：限制单次高亮的最大代码长度，超过 8000 字符的代码块改在requestIdleCallback里分批高亮，避免阻塞主线程。
还有一个小技巧：CSS 选择器避免过深嵌套。渲染层在 patch 时如果使用querySelector('.container .content .markdown-body .table-wrapper tr')这种深路径，每次 DOM 查询都会遍历大量节点。我改成给每个块节点分配一个>// Markdown 增量解析器骨架 export class IncrementalMarkdownParser { constructor() { this.reset(); } reset() { this.stack = []; this.buffer = ''; } append(chunk) { this.buffer += chunk; const patches = []; // 按行扫描，维持状态机 let newlineIndex; while ((newlineIndex = this.buffer.indexOf('\n')) >= 0) { const line = this.buffer.slice(0, newlineIndex + 1); this.buffer = this.buffer.slice(newlineIndex + 1); this.feedLine(line, patches); } return patches; } feedLine(line, patches) { const top = this.stack[this.stack.length - 1]; // 简化示例：只处理标题和普通段落 if (line.startsWith('### ')) { patches.push({ op: 'append', node: { type: 'h3', text: line.slice(4) } }); return; } // 其他块级元素类似：列表、引用、表格、代码块 } }
补丁生成器与渲染器：
// 渲染器：根据 patch 操作 DOM export class PatchRenderer { constructor(root) { this.root = root; this.nodeMap = new Map(); } apply(patches) { for (const patch of patches) { if (patch.op === 'append') { const el = this.createElement(patch.node); this.root.appendChild(el); this.nodeMap.set(patch.node.id, el); } else if (patch.op === 'updateText') { const el = this.nodeMap.get(patch.nodeId); el.textContent = patch.text; } // 更多 op 分支：update, appendChild, destroy... } } }组件注册表：
// 生成式 UI 组件注册表 export class ComponentRegistry { constructor() { this.components = new Map(); } register(name, factory) { this.components.set(name, factory); } create(name, props, mountPoint) { const factory = this.components.get(name); if (!factory) { const fallback = document.createElement('div'); fallback.textContent = '[未知组件: ' + name + ']'; return fallback; } const instance = factory.create(props); mountPoint.appendChild(instance.root); return instance; } }这个骨架在实际项目中跑起来后，核心的工作量会转移到两块：完善解析器的 Markdown 块类型覆盖，以及扩展组件注册表的业务组件。解析器的每个分支都可以单独写单元测试，尤其是表格和代码块的状态切换，最好用固定样例数据反复验证。
生产环境中，我建议把解析器放到 Web Worker 里运行。主线程只负责 DOM 操作，解析和补丁生成都丢给 Worker，这样即使文档很大也不会阻塞用户交互。主线程和 Worker 之间用postMessage传递 patch 数组，数据结构保持可序列化。
9. 从个人经验出发的几点忠告
踩过不少坑之后，我越来越觉得流式渲染和生成式 UI 的工程化，核心不在于某一种框架或某一个库，而是一套稳健的架构分层。如果你打算把这套能力落地到自己的项目里，我给你几个经验层面的建议。
解析器和渲染器一定要解耦。很多人喜欢把 Markdown 解析逻辑直接写在 React 组件里，图省事。但组件是易变层，解析器是核心逻辑层，混在一起会让单元测试变得极其困难。我见过一个团队把所有逻辑写在一个 2000 行的组件里，最后改一个表格样式都要提心吊胆。正确做法是解析器做成纯函数或者纯类，不依赖任何 UI 框架，这样可以用 Node 环境直接跑测试。
增量解析的测试用例要尽早沉淀。流式场景的特殊之处在于“任何阶段都可能中断又恢复”。准备一份包含标题、列表、代码块、表格、嵌套引用、组件声明共六种类型的长文档样本，在测试环境里按 1 个字符、5 个字符、100 个字符三种粒度切分，分别验证解析结果是否一致。这套测试能帮你拦住至少 30% 的边界 bug。
生成式 UI 一定要做能力边界的版本管理。AI 输出的组件类型不是固定的，今天新增一种，明天可能废弃一种。组件注册表要带版本字段，组件声明里也要带版本号，前后端约定好兼容策略。不要让旧数据流里突然冒出一种前端不认识的新组件类型，否则整个页面渲染都会被拖垮。
性能优化不要一上来就上重型方案。可以先跑一个最简版本，量出主要瓶颈，再针对性地引入 Web Worker、虚拟滚动、增量高亮。上来就堆全套优化会导致代码复杂度飙升，排查问题时反而更加痛苦。我见过很多人把最简单的流式聊天页面做成了微前端架构，最后项目跑不动了还找不到问题，纯粹是过度设计害的。
写这篇文章时，我脑子里一直有一个朴素的标准：用户打开一个 AI 应用，他希望第一眼看到的是顺滑的“打字机”效果，而不是白屏等待，更不是格式错乱的半成品。流式渲染就是为这个目标服务的，它做得好，用户感受不到它的存在；做得不好，它就是灾难现场。生成式 UI 是下一步的自然演化，但要走到那一步，先把文本流的渲染体验做到极致，是最值得投入的一件事。
