流式对话前端实现：SSE与Markdown渲染的工程之痛

这帖子看得我挺有共鸣的，楼主提到的几个点确实都是我们在实际落地AI对话前端时反复踩过的坑，尤其是SSE流式数据与Markdown渲染的耦合问题，这几乎是所有AI对话项目从“能跑”走向“好用”过程中必须跨越的一道坎。我不打算泛泛地谈理论，而是结合我们团队在多个项目中的真实经历，把一些关键的技术细节、架构取舍以及我在思考这个领域未来走向时的一些判断，系统地展开聊一聊。

先说SSE与Markdown渲染的耦合问题。楼主提到字节流中断导致Markdown解析异常，比如代码块被切分到多个chunk中，这确实是表面现象，但深层次的问题在于：Markdown解析器本质上是面向完整文本的，而SSE流式输出是面向字节流的。这两个模型在底层哲学上就是冲突的。我们最初的做法跟楼主类似，在客户端维护一个缓冲区，等收集到完整的语法块后再渲染。但很快发现，这种方案在代码块长度超过几十行时，用户等待时间会明显变长，打字机效果的实时感几乎消失。后来我们换了一种思路：不再等待完整块，而是对不完整的Markdown进行容错渲染。具体做法是，在每次收到新的chunk时，将当前已累积的文本拼接后传递给一个支持流式输入的Markdown解析器，这个解析器必须能够在遇到未闭合的标记时做出合理的“最佳猜测”。比如对于代码块，如果当前文本以三个反引号开头但没有闭合，解析器就跳过代码块渲染，只显示原始文本，同时记录状态，等后续chunk补齐后立即切换渲染模式。这实际上是把“等待”的成本从用户感知层面转移到了渲染引擎内部，用户看到的始终是渐进的、实时的内容，即使代码块在中间某个时刻显示为普通文本，也只是瞬间的，下一帧就会被正确渲染。这种方案的代价是需要自己维护一个状态机，或者对现有的Markdown解析库做扩展。我们当时基于marked库做了二次开发，在它的tokenizer层插入了一个“流式上下文”对象，专门跟踪未闭合的块级元素。如果你用的解析器不支持这种扩展，也可以考虑在渲染层做后处理：比如用虚拟DOM diff来检测上一次渲染中哪些部分是不完整的，然后以占位符覆盖，直到完整后再替换。这听起来复杂，但实际上只要你对React或Vue的更新机制足够熟悉，实现起来并不比缓冲区方案复杂多少，而且用户体验的收益是显著的。

关于楼主提到的AbortController中断生成，这个点我特别想展开说。很多团队确实只关注正向流程，但我觉得更严重的问题是中断后的状态管理被严重低估了。我们曾经在一个项目里遇到一个非常隐蔽的bug：用户连续多次中断并重新发起对话，每次中断后都会残留一个未清理的SSE连接，导致浏览器在几分钟内内存暴涨，最终页面崩溃。调试后发现，问题出在中断时只调用了AbortController的abort方法，但没有显式关闭EventSource实例。更隐蔽的是，有些浏览器实现中，EventSource在收到abort信号后会尝试重新连接，如果服务器端没有正确处理这个信号，就会导致连接无限重试。我们的解决方案是，在中断时不仅要调用abort，还要手动调用EventSource的close方法，并且将相关的状态（比如已累积的文本、渲染队列、动画帧ID）全部重置到一个干净状态。另外，对于低端设备上的卡顿问题，我补充一个容易被忽视的点：中断后，之前启动的requestAnimationFrame动画循环不会自动停止，除非你显式调用cancelAnimationFrame。我们遇到的情况是，用户在中途取消后，页面上虽然停止了文本追加，但之前的动画帧还在继续执行，不断尝试更新已经不存在的DOM节点，导致CPU占用居高不下。解决办法很简单：在中断时遍历所有活跃的动画帧ID并逐个取消，同时清理所有未执行的setTimeout和setInterval。这些细节看起来琐碎，但恰恰是这些“清理工作”决定了产品的稳定性。

楼主问到的两个具体问题，我逐一分享我们的实践。第一个是SSE长连接下的心跳保活。我们最初的做法是在服务端每隔15秒发送一个自定义的ping事件，客户端监听这个事件来重置超时计时器。但这个方案有个明显的缺陷：如果服务端负载过高，ping事件可能被延迟，而客户端误判为连接断开。后来我们改用了更激进的双向心跳机制：客户端每隔10秒主动发送一个GET请求到心跳端点，服务端返回一个简单的ack，同时服务端也会在SSE流中定期发送keepalive事件。客户端只有在连续三次既没收到服务端keepalive、也没成功发起心跳请求时，才判定连接断开。这个方案大大减少了误判。但更根本的解法是，如果你的后端架构支持，可以考虑将SSE长连接改为WebSocket，因为WebSocket协议本身就支持心跳ping/pong帧，不需要应用层额外实现。当然，WebSocket在部署时对网关和负载均衡器的要求比SSE高，这是一个权衡。如果你坚持使用SSE，我建议至少做到两点：一是服务端的心跳事件要独立于主数据流，不要因为主数据流的阻塞而影响心跳；二是客户端的超时判断要基于“最后收到任何数据的时间”，而不是只盯着心跳事件，这样即使某次心跳丢失，只要主数据流还在传输，就不会误断。

第二个问题是超长代码块的流式渲染。楼主说比分段解析更优雅的方案，我认为“优雅”的前提是接受一个事实：在流的场景下，没有完美的实时渲染方案，只有最适合业务场景的取舍。我们尝试过三种方案。第一种是楼主提到的缓冲区，等完整代码块结束再统一渲染，这个方案牺牲了实时性，但在代码块长度不超过几百行时，用户感知不明显，而且实现最简单。第二种是我前面提到的容错渲染，对不完整代码块做最佳猜测，这个方案实时性最好，但遇到多层嵌套的复杂Markdown结构时，容错逻辑会变得非常复杂，甚至可能出现渲染闪烁。第三种是一个比较取巧的方案：不渲染代码块本身，而是渲染一个“代码块占位符”，比如一个带有加载动画的卡片，等代码块完整传输完毕后，再替换为高亮的代码块。这个方案在视觉上既保持了打字机效果的连贯性，又避免了格式错乱，用户看到的是一个逐渐填充的代码区域，而不是跳变的文本。我们最终在产品中采用了第三种方案，因为它对用户最友好，而且实现代价最小。你只需要在Markdown解析器中识别出代码块的起始标记，然后立即渲染一个固定高度的占位容器，后续每次收到新的chunk时，将累积的代码文本作为该容器的内部文本追加，但容器本身的高亮和样式在完整之前不生效。等到代码块闭合标记到达时，再对整个容器进行一次完整的高亮渲染。这个过程中，用户看到的是一行一行逐渐出现的原始代码文本，虽然缺少语法高亮，但保持了信息的实时可达性，而语法高亮只在最终瞬间完成，这种“先有内容，后有样式”的体验，其实比等待很长时间然后突然出现一个完整代码块要好得多。

从行业趋势来看，我非常认同楼主的判断：这类基础组件正从“能跑就行”转向“体验打磨”。但我对“未来前端框架可能会内置流式渲染的原生支持”这个观点持谨慎乐观态度。我不认为主流框架（React、Vue、Angular）会直接内置SSE和Markdown渲染的耦合方案，因为这太业务特定，框架层面做这种抽象容易过度。更有可能的路径是，围绕AI对话场景会涌现出一批专门的库或SDK，比如类似SWR或TanStack Query那样，但专门针对流式数据的获取、解析、渲染和中断管理做封装。事实上，现在已经有一些雏形了，比如Vercel的AI SDK就提供了useChat hook，直接封装了SSE连接、中断、流式文本渲染等逻辑，但它在Markdown渲染方面做得还比较浅，主要依赖客户端自己处理。我猜测未来一到两年内，会出现一个更成熟的“流式渲染引擎”，它不再只是处理字符串追加，而是能理解Markdown的语法结构，在流式输入下自动管理状态机，甚至支持插件化的自定义语法渲染。这个引擎可能会像Quill或ProseMirror那样，成为一个独立于框架的中间层，然后在React、Vue等框架中通过适配器使用。

最后，我想补充一个帖子中没有提到但我觉得很重要的点：SSE流式对话中的错误处理与重试策略。很多实现只考虑了正常情况下的流式渲染，但忽略了网络抖动或服务端错误导致流中断后的恢复。我们的做法是，在客户端维护一个“已确认接收的字符位置”的游标，每次成功渲染后，将这个游标更新到服务端。如果流中断，重新连接时，客户端带着这个游标发起新的SSE请求，服务端从该位置继续输出。这个机制要求服务端也支持断点续传，但实现起来并不复杂，只需要在SSE的data事件中附带一个递增的序列号即可。配合这个机制，心跳保活的意义就不仅仅是检测连接是否存活，更是为了在流中断后能够快速恢复到正确的进度，而不是从头开始。这对于长对话或超长代码块的渲染来说，体验提升非常明显。

总结一下，我觉得处理SSE与Markdown渲染的耦合问题，核心不在于找到一个一劳永逸的完美算法，而在于理解业务场景的优先级：是更看重实时性，还是更看重格式完整性，还是更看重实现复杂度。不同的优先级会导向不同的技术选型，没有绝对的对错。但无论选择哪种方案，都需要在中断管理、心跳保活、错误恢复这三个维度上做充分的防御性编程，因为AI对话场景下的网络环境和服务端行为远比传统HTTP请求复杂。希望我的这些经验能对楼主和正在阅读的同行们有所帮助，也期待看到更多关于这个方向的深度讨论。

看到这个帖子，真的很感慨。你提到的“字节流中断导致Markdown解析异常”，我在项目里至少被它折磨过三轮，每次都是看似解决了，换个场景又冒出来。先说说代码块分片的问题吧，这确实是SSE流式渲染里最典型的“隐形炸弹”。

我最初的做法跟你类似，用缓冲区拼字符串，等检测到```闭合再一次性渲染。但很快发现两个问题：第一，用户如果中途打断对话，缓冲区里的半截代码块就永远无法闭合了；第二，超长代码块比如上千行的JSON或日志，用户要等整个缓冲区攒完才看到内容，打字机效果名存实亡。后来我们换了一种思路：不再追求“完整代码块再渲染”，而是把Markdown解析器改成“增量解析”模式。具体做法是维护一个可变长度的“上下文窗口”，每次收到新chunk时，把当前已渲染的内容和新增内容拼接成临时字符串，用marked.js之类的解析器尝试解析，但只渲染新增的差异部分。对于代码块，我们会在渲染层做特殊处理——如果检测到当前处于未闭合的代码块内，就提前在渲染结果里插入一个“占位符容器”，后面每次追加内容时只更新这个容器的innerHTML，而不是重建整个DOM。这样既保留了逐字输出的感觉，又不会因为分片导致格式错乱。

当然，这个方案有个前提：你得能准确判断当前chunk是否属于代码块内部。我是通过维护一个状态机来实现的，记录当前是否在代码块、是否在行内代码、是否在表格或列表里。每收到一个chunk，先跑一遍状态机，再决定是直接追加文本还是触发特殊渲染逻辑。这个状态机本身也有坑，比如嵌套代码块（比如markdown文档里放代码块示例），或者代码块里夹杂HTML标签，都容易让状态机跑飞。我们最后妥协了一版：只支持单层代码块，嵌套场景直接降级为普通文本，先保证95%场景的体验。

关于你问的心跳保活，我踩过的坑是“心跳检测和UI更新抢线程”。早期我们用setInterval每30秒发一次ping，但发现如果后台模型生成慢，心跳包和SSE数据流会同时到达，导致浏览器把两次事件合并成一次渲染，造成视觉上的“卡一下然后跳一大段”。后来我们改成用SSE协议自带的retry机制兜底，前端不主动发心跳，而是监听SSE连接的onerror事件。如果连续3次重试失败，再触发UI层面的断连提示。这个做法减少了不必要的网络交互，但对后端要求高——后端必须定期发送注释行（比如:heartbeat\n）来维持连接，而且注释行的间隔不能太短，否则移动端功耗会飙升。我们最终定在20秒一次，实测在4G网络下比较稳妥。

至于超长代码块的流式渲染，说实话“分段解析”目前还没看到真正优雅的通用方案。我尝试过两种变体：第一种是“虚拟滚动+流式注入”，类似列表渲染的虚拟化思路，只渲染视口内的代码行，但问题在于代码块通常是连续滚动的，用户可能会从中间开始看，虚拟滚动会导致行号错乱。第二种是“Web Worker里跑解析”，把字符串拼接和状态机计算放到Worker线程，主线程只负责DOM更新。这个方案在桌面端效果很好，但在移动端Worker的创建和通信开销反而拖慢了整体速度，最终我们只在PC端启用，移动端降级为普通缓冲区方案。如果现在让我重新设计

，我可能会考虑用浏览器原生的MutationObserver来监听文本节点的变化，配合requestAnimationFrame做批处理，但这需要浏览器提前返回未闭合的DOM结构，目前只有部分现代浏览器支持。

你提到的AbortController中断清理，我补充一个容易被忽视的点：中断后不仅需要清理SSE连接和动画帧，还得重置Markdown状态机。我之前遇到过一个bug：用户快速点击“停止生成”再重新发送，结果新对话的SSE流里混入了上一个对话未闭合的代码块状态，导致新对话里所有文本都被当成代码块渲染。后来的做法是在每次中断时，强制把状态机重置到初始态，并且清空缓冲区里的残留字符串。另外，中断时如果已经渲染了部分代码块，最好在UI上保留一个“代码块断点标记”，比如显示一行红色虚线提示“内容被截断”，而不是直接删除已渲染内容。很多用户会盯着屏幕等结果，突然消失会让他们以为系统出错了。

从架构角度说，这类组件确实正在从“能跑就行”走向“体验打磨”。我观察到的一个趋势是，越来越多的团队开始把流式渲染和状态管理解耦，比如用Redux或Zustand维护一个“消息流快照”，渲染层只做纯展示。这样有个好处：当用户中断后重新生成时，可以快速回滚到中断前的快照，而不是重新建立SSE连接。缺点是快照本身也会占用内存，如果一个对话包含几十个代码块，快照体积可能达到几MB，在低端设备上容易触发OOM。我们最终的做法是只保留最近5条消息的完整快照，更早的消息只保留纯文本摘要。

最后聊点行业趋势。你提到“前端框架内置流式渲染”，我其实有点悲观。React和Vue的响应式系统本质上是基于“状态变更驱动视图更新”，而流式渲染要求的是“持续追加式更新”，这两者的底层逻辑是冲突的。React Server Component虽然支持流式传输，但它更偏向服务端渲染，对于纯前端的Markdown流式解析并没有直接帮助。我反而觉得，未来更可能的进化方向是浏览器API层面的支持。比如Fetch API如果能直接返回一个可中断的ReadableStream，并且配合新的DOM API支持“部分解析的HTML片段”，那前端就只需要关注业务逻辑了。目前已经有提案在讨论类似的能力，但离落地至少还有两三年。

在那之前，我们可能还是要继续手写Hook。不过可以换个角度想：这些“工程之痛”恰恰是技术深水区的标志，当别人还在为“能跑就行”沾沾自喜时，你已经在思考“如何跑得更优雅”了。等你把缓冲区管理、状态机、Web Worker、虚拟滚动这些坑都趟平了，这套组件就是团队的核心竞争力。毕竟，在AI对话产品里，流式渲染的流畅度直接决定了用户对“智能感”的第一印象——哪怕模型能力再强，如果前端卡得像PPT，用户也会觉得这AI“不聪明”。

最后提醒一点：记得给这套组件加上详细的性能埋点。我们上线初期发现，某款中端手机在渲染代码块时CPU占用率飙到90%，排查了半天发现是marked.js的代码高亮插件在增量解析时重复计算了行号。后来换成轻量级的Prism.js配合自定义分词器才解决。这类问题光靠肉眼很难发现，必须有数据支撑才能定位。

看到这篇帖子，我深有同感。SSE流式对话与Markdown渲染的耦合问题，确实是从“能跑就行”到“体验打磨”过程中最磨人的细节之一。我在过去两年里深度参与了三个AI对话产品的前端架构设计，从早期的简单fetch轮询到现在的EventSource + 缓冲区 + 流式渲染，几乎踩遍了所有能踩的坑。下面我结合自己的工程实践，从几个维度展开聊聊。

先说Markdown渲染与SSE字节流中断的问题。帖子里提到的代码块分割问题，我称之为“块边界污染”。实际场景中，不仅代码块标记符可能被切分，内联代码、表格、甚至列表标记符都可能被切分。比如用户输入“请用Python写一个快速排序”，模型输出可能是一个完整的代码块，但SSE的chunk大小取决于服务端flus策略和网络MTU。我曾经遇到过某云厂商的API网关默认对SSE推送做了8KB的分片，一个500行的Python代码块被切成了7个chunk，每个chunk里都包含半个或者半个def。这种情况如果直接丢给marked.js或者marked的流式解析器，会出现大量的临时渲染错误，比如突然出现一个未闭合的代码块高亮，或者表格的竖线|被错误解析成强调。

我的解决方案是一个三层缓冲区架构。第一层是原始字节缓冲区，负责拼接SSE的data字段；第二层是块结构缓冲区，基于正则和状态机识别Markdown的块级元素边界，比如代码块的```、引用块>、水平线---等；第三层是渲染缓冲区，只将已确认完整的块级元素传递给渲染引擎。这个架构的代价是延迟——用户会在代码块结束时才看到完整渲染，但好处是彻底避免了渲染错乱。实际测试中，对于普通对话场景（非专门写代码），90%的代码块在1-2个chunk内就能完成，用户几乎感知不到延迟。只有极少数超长代码块（比如超过200行）会有明显的“突然出现”感，这时我会在代码块开始位置显示一个“正在生成中...”的骨架屏占位符，并在代码块结束时替换为实际内容。这比逐字渲染但频繁重绘导致闪烁要好得多。

关于AbortController和状态清理，帖子里说得很到位。我补充一个容易被忽视的细节：AbortController不仅仅用于中止fetch请求，还需要与React的useEffect cleanup、动画帧的cancelAnimationFrame、以及SSE的EventSource.close()形成联动。我曾经遇到过一个问题：用户在对话过程中快速点击“停止生成”按钮，然后立即发送新消息。这时旧SSE连接可能还没完全关闭，新SSE连接已经建立，导致两个流同时写入同一个聊天窗口的数据状态。我的做法是在全局维护一个generationAbortControllerRef，每次开始新请求时先执行一次abort（如果存在），再创建新的AbortController。同时，在SSE的onmessage回调中检查aborted标志位，如果已被中止则忽略后续所有事件。这看起来很简单，但我见过很多团队只在点击停止时调用了abort()，却没有在回调中做防御性检查，结果就是用户停下来后，缓冲区里残留的几个chunk还会触发UI更新，造成“幽灵打字”效果。

回到帖子里提到的两个具体问题。第一个是SSE长连接下的心跳保活。我见过两种主流方案：一种是服务端每隔30秒发送一个自定义的ping事件，比如event: ping\ndata: {}\n\n，前端在onmessage里监听ping事件并重置心跳超时计时器。另一种是利用HTTP/2的PING帧，但这要求服务端和客户端都支持HTTP/2，而且浏览器对EventSource的HTTP/2支持并不一致。我们团队最终选择了第一种方案，并加了一个降级逻辑：如果超过60秒没有收到任何事件（包括ping），就主动断开连接并尝试重连。这里有个坑：某些代理服务器或CDN可能会过滤掉自定义事件类型的SSE消息。我在生产环境遇到过某云厂商的WAF将event: ping识别为异常流量并直接切断连接。最后我们不得不把心跳实现为发送一个空数据的message事件，而不是自定义事件类型。另外，心跳也解决了浏览器后台标签页进入休眠后SSE连接被冻结的问题。当用户切回标签页时，心跳超时检测会触发重连，确保对话界面不会“冻住”。

第二个问题是超长代码块的流式渲染。前面提到了三层缓冲区架构，但针对超长代码块，我还有一个更激进的优化：分块渲染+延迟合成。具体来说，对于超过50行的代码块，我会在接收到第一个chunk时就开始渲染代码块的开头部分，但只渲染纯文本（不启用语法高亮），同时启动一个200ms的防抖计时器。在后续chunk到达时，只更新代码块的文本内容，不触发SyntaxHighlighter的重渲染。直到防抖计时器触发（即连续200ms没有新chunk），才执行一次完整的语法高亮渲染。这样用户可以看到代码逐行出现，但不会因为每次重绘都做语法分析而卡死UI。这个方案需要精确控制防抖阈值——太短会导致频繁高亮渲染，太长会让用户感觉代码出现后很久才有颜色。我们通过A/B测试将阈值定在了150ms-250ms之间，视代码块长度动态调整。另外，对于特别长的代码块（比如超过200行），我还引入了虚拟滚动：只渲染可视区域内的行，上下各留50行的缓冲区。这确实提升了长代码块下的帧率，但实现复杂度也上了一个台阶，需要同时管理Markdown解析、代码高亮和虚拟滚动三者的状态同步。

从更宏观的角度看，这类基础组件从“能跑就行”到“体验打磨”的转变，实际上是AI对话产品从粗放增长走向精细化运营的必然结果。早期大家关注的只是“能不能把流式文本显示出来”，现在用户期望的是“像真人打字一样流畅自然”。这背后涉及SSE协议优化、前端渲染性能、状态管理、错误恢复等多个层面的系统工程。我注意到有些团队开始尝试使用WebSocket替代SSE来获得更灵活的控制，比如支持二进制帧、自定义心跳、更精细的流控。但WebSocket的缺点也很明显：需要自己实现协议解析、重连逻辑、消息序列化等，不如SSE开箱即用。我个人的判断是，未来一到两年内，浏览器原生可能会推出类似“Streaming HTML”或“Streaming Markdown”的API，让渲染引擎直接支持增量更新。现在已经有了一些实验性的提案，比如HTML Streams API和CSS Content Visibility的流式版本。届时，很多手写的Hook和缓冲区逻辑都可以被平台能力替代。

最后，我想分享一个在团队内部推行的“流式渲染自检清单”，供大家参考。第一，是否处理了chunk边界分裂（包括代码块、内联代码、表格、列表、HTML标签）？第二，是否实现了中断后状态清理（AbortController + EventSource.close + cancelAnimationFrame）？第三，是否有心跳保活机制和重连策略？第四，是否对长代码块做了延迟高亮或虚拟滚动优化？第五，是否在服务端做了输出格式标准化，比如强制在代码块前后加换行、统一缩进风格？第六，是否在用户切换标签页或网络波动时能够优雅恢复？这六点都做到位了，流式对话的体验才算是“及格线”以上。至于“优秀”，那就需要结合具体业务场景做个性化打磨了，比如数学公式的流式渲染、表格的逐步构建、甚至流式图表生成，那又是另一个维度的工程挑战了。

总的来说，SSE与Markdown渲染的耦合问题，本质上是“流式数据的非结构化输出”与“结构化渲染引擎”之间的矛盾。解决这个矛盾没有银弹，只能在缓冲区架构、渲染策略、用户体验之间做权衡。希望我的经验能给大家一些参考，也期待看到更多团队分享自己的方案。毕竟这类基础组件的成熟，需要整个社区一起踩坑和沉淀。

缓冲区那块太真实了，我试过用虚拟滚动+分段渲染，但代码块被切分时还是容易炸，最后妥协成先攒够完整```再输出，实时性确实打折扣。中断清理这块也踩过坑，AbortController取消后没及时断开SSE，结果用户快速重试时连接堆积，页面直接卡死。

缓冲区方案确实能解决代码块截断问题，但实时性损失有点大。我试过用流式解析器边收边渲染，对代码块标记做状态机匹配，遇到不完整标记先占位，等下一个chunk补全再刷新，打字机效果基本能保住。AbortController那个坑我也踩过，现在习惯在finally里统一清理SSE和定时器，防止低版本浏览器残留连接。

缓冲区+牺牲打字机效果这个取舍太真实了，我也在这块翻过车。刚开始图省事直接往Markdown渲染器里喂流式数据，结果代码块被切成两半的时候，渲染器直接漏了结尾的```，整个页面样式都崩了。后来试过用正则匹配代码块头尾，但遇到嵌套或者特殊字符又得打补丁，最后索性在SSE回调里维护一个临时栈，碰到代码块开始标记就攒着，等结束标记到了再一起吐出，效果还行，就是逻辑复杂度上去了不少。

AbortController那个点确实容易被忽略，特别是中断后如果SSE的onerror回调里还残留着setState，低端机型上直接白屏。我现在的做法是中断时先把abort信号挂到ref上，所有异步回调里先检查这个ref，再配合清理函数把未完成的requestAnimationFrame和SSE实例都干掉。另外提一个补充：流式渲染时的节流策略也很关键，如果每收到一个chunk就触发重渲染，高频更新会导致Markdown解析器反复重建DOM，尤其是大段列表或表格，肉眼可见的卡顿。我这边用了一个定时器，每50ms合并一次缓冲区内容再渲染，打字机效果基本看不出延迟，但CPU占用能降一半。你们团队在处理流式Markdown解析时，有没有遇到表格或者任务列表被截断的情况？这俩是我目前还没彻底解决的痛点。

缓冲区那个方案我也踩过类似的坑，后来用了个取巧的办法：把内容先按行拆分缓存，遇到不完整的代码块标记就等下一个chunk补全再渲染，实时性损失小很多。不过遇到超长代码块还是会有延迟感。另外想问下，中断时你们是怎么处理已渲染但未闭合的Markdown标签的？我直接清空重新渲染会导致内容闪烁，挺头疼的。

缓冲区那点我太有同感了。我之前也试过攒chunk等完整代码块再渲染，结果用户反馈打字机效果卡顿感明显，尤其是长代码块的时候，用户体验很割裂。后来换了个思路：用两阶段渲染，先按字符流实时显示纯文本，同时用另一个缓冲区专门拼代码块，等代码块闭合标记到了再替换掉之前临时渲染的文本节点。这样打字机效果基本不受影响，代码块也能正常高亮，就是实现起来DOM操作要小心一点，得用虚拟节点对比或者直接操作innerHTML的片段替换。

AbortController那个坑我也踩过。之前项目中只关了SSE连接，没处理React组件的异步状态，结果用户快速取消再重新生成时，旧的setState还在执行，导致UI闪一下旧数据。后来统一在useEffect的cleanup里调用abort，并且加了个ref标记来判断组件是否挂载，setState前检查一下，才彻底解决。

另外想请教一下，作者提到的Hook封装流式数据，有没有考虑过SSE断线重连的场景？我们这边用户网络环境复杂，有时候SSE连接会突然断开几秒，如果直接抛异常重连，用户看到的就是输出中断然后重新从0开始，体验很糟糕。目前我们是在客户端维护一个消息队列，断线后自动重连并请求服务端从断点继续推流，但这样服务端也得配合改，挺麻烦的。你们是怎么处理这个场景的？