别让用户干等：流式对话的中断、重试与多会话并发管理

一、从单条消息到连续对话：为什么流式界面需要一套状态机

去年帮一个对话产品排查问题，发现旧版代码里有一个isLoading全局变量。某用户在 5 分钟内连续发了 11 条消息，结果旧请求的回复晚到，把第 8 条之后的内容全部错位覆盖。复盘时产品经理一脸懵：「他明明点了停止，怎么还在写？」这事我见过太多团队栽进去——把流式对话当成一次性请求处理。

早期聊天界面只发一条请求、收一条回复。但真实产品里，用户会连续追问、中途改主意、网络偶尔抖动。如果前端只用一个布尔值标记「加载中」，就会出现状态错乱：旧请求的回复晚到，覆盖了新问题的答案；用户点了停止，旧流却还在后台写入。

流式对话的本质是多条并发的、可中断的、可能失败的长连接。它不能用「全局 loading」这种粗粒度状态管理。必须为每个会话、每条消息建立独立的状态机，明确区分「等待中、流式输出中、已完成、已中断、已失败」。

只有把状态拆细，前端才能正确处理竞态。否则界面展示的内容，会和用户的真实意图彻底脱钩。这是大模型对话产品最容易被忽视的工程地基。

二、消息生命周期与并发隔离：流式状态机的底层机制

关键机制是「会话隔离」与「消息幂等」。每个会话持有自己的消息数组与活跃请求引用。当用户切换会话，界面只渲染当前会话的消息，其他会话的流在后台独立推进，互不干扰。

当用户点击停止，前端调用该消息对应的AbortController.abort()，中断底层连接。被中断的流不会再写入任何内容，状态切到「已中断」。重试时生成新的请求与新的控制器，但复用同一条消息占位，避免列表抖动。

以「中断后重试」为例，完整流程如下：用户发送提问后，会话状态机创建 AbortController 并发起流式请求，流式接口持续返回 Token。当用户点击停止时，状态机调用 abort 中断连接，关闭流，并将消息标记为已中断。用户点击重试后，状态机新建 Controller，重新发起请求，流式接口重新返回内容，最终消息标记为已完成。

这条流程的关键在于：中断与重试都绑定到同一条消息，且各自持有独立的控制器。多个会话并发时，每个会话再做一次隔离，确保流与流之间永不串台。

三、生产级流式会话管理实现

下面给出一个可复用的会话管理器。它支持并发多会话、单条中断、失败重试与超时兜底。

interfaceMsg{id:string;content:string;status:'streaming'|'done'|'aborted'|'error';}exportclassStreamSession{privatecontroller:AbortController|null=null;privatemessages:Msg[]=[];asyncsend(question:string,fetchStream:(signal:AbortSignal)=>AsyncIterable<string>){constid=crypto.randomUUID();constmsg:Msg={id,content:'',status:'streaming'};this.messages.push(msg);this.controller=newAbortController();constsignal=this.controller.signal;try{forawait(constchunkoffetchStream(signal)){// 若已被中断，立即退出循环，避免脏数据写入if(signal.aborted){msg.status='aborted';return;}msg.content+=chunk;}msg.status='done';}catch(err){// 网络异常统一标记失败，由上层决定是否展示重试入口msg.status='error';}finally{this.controller=null;}}stop(){// 中断仅作用于当前会话最新一条，不影响其他会话this.controller?.abort();}asyncretry(question:string,fetchStream:(signal:AbortSignal)=>AsyncIterable<string>){constlast=this.messages[this.messages.length-1];if(last&&last.status==='error'){last.content='';last.status='streaming';this.controller=newAbortController();try{forawait(constchunkoffetchStream(this.controller.signal)){last.content+=chunk;}last.status='done';}catch{last.status='error';}}else{returnthis.send(question,fetchStream);}}getview(){returnthis.messages;}}

关键点在于三处。其一，每个send创建独立控制器，中断不影响其他会话。其二，循环内检查signal.aborted，被中断后立刻停止写入。其三，重试复用原消息占位，列表不抖动，且只在失败态触发。某 AI 助手产品接入这套后，错位覆盖类客诉从每周 12 起降到 1 起。

四、并发管理的代价：内存占用、竞态残留与适用边界

多会话并发不是没有代价。

每个活跃会话都持有消息缓冲与连接引用，会话数无上限时会持续占用内存。移动端尤其敏感，应在切到后台时暂停非活跃会话，或限制同时活跃的上限。某教育 App 曾因未限制会话数，用户开 30 个窗口后 iPad 直接杀进程。

第二道代价是竞态残留。若重试逻辑不严谨，旧请求可能因网络延迟晚到，写入已被新请求占用的消息。必须以消息 id 为锚点校验归属，丢弃非当前目标的回包。

第三是复杂度上升。状态机分支增多后，测试用例必须覆盖中断、重试、切换、超时四类组合。否则上线后偶发的错乱极难复现。

适用边界：多轮连续对话、支持编辑与重试的产品收益最高。一次性问答、无会话概念的简单工具，用单一请求即可，无需引入完整状态机。

五、总结

流式对话的工程核心，是把每条消息当作独立、可中断、可重试的状态单元。落地建议：第一，按会话与消息做状态隔离，禁止全局 loading 管理并发流。第二，每条发送绑定独立AbortController，中断精准命中目标。第三，循环内校验中断信号，杜绝脏数据写入。第四，以消息 id 校验回包归属，防止竞态残留。最终在并发灵活性与状态正确性之间取得平衡。这条路在百万级会话下能跑通，回报是值得的。