流式输出的三个作用
第一，降低等待焦虑：用户看到内容在生成，就不觉得卡死。第二，建立过程信任：用户能看到 AI 先理解再回答。第三，支持早期打断：答案不对时可以立刻停止。
如果只是把整段答案一次性返回，再打字机式播放，本质上是在欺骗用户，体验并没有变好。
实现上的注意点
服务端用 SSE 或 WebSocket 推送增量，前端按增量渲染，并保持光标、复制、选择等操作可用。关键是要处理好中断：用户停止生成后，服务端也必须真正停止，而不是继续消耗 token。
- 增量渲染保持可选中、可复制
- 停止生成要同时取消服务端任务
- 断线重连后补齐已生成内容
不只是聊天框
流式输出可以用于分析报告、代码生成、长文档、图片生成进度。渐进式展示步骤和中间结果，比让用户盯着一个转圈图标更有价值。
设计原则：用户随时知道「进行到哪一步、还需要多久、能否取消」。
给流式结果一个落点
流式生成的最终结果应该沉淀为可保存、可分享、可编辑的对象，而不是只停留在对话里。
流式是过程，结构化保存才是结果。
什么时候不做流式
回答很短、生成时间低于一秒、或者结果需要整体校验后才能展示时，流式反而增加复杂度。
流式的价值与生成时长成正比：生成越长，过程可见越重要。先算清楚用户等待时间，再决定要不要流式。
流式状态的前端封装
把流式连接封装成自定义 Hook 或状态机组件，界面层只消费状态：idle、connecting、streaming、done、error。业务组件不用关心底层协议。
封装里要处理三类细节：网络中断后的重连、服务端提前结束、用户停止生成后的清理。这些细节漏掉一个，线上就会出现「光标还在跳，内容却不动」的卡死。
封装做好后，任何页面要接入 AI 对话，只需要声明状态和渲染函数，团队效率会明显提升。
流式与并发
流式输出会放大并发问题：每个连接都占着服务端资源，用户一多，成本飙升、延迟变长。发布前要估算同时在线会话数，给每个用户设置并发上限。
前端也要防止用户在一个页面同时发起多个生成任务，必要时用队列串行执行。
流式体验的稳定性，一半在协议实现，一半在并发控制。