高并发团队的七步服务器发送事件上线清单
批量生成、长文分析和多人协作一旦进入持续高负载，前端就不能只把完整回答改成逐字显示。服务器发送事件让结果持续到达，但连接、解析和计费边界必须一起设计。
01 · 第一步：把密钥留在后端代理
浏览器只访问团队后端，由后端携带密钥请求上游，并转发事件流。接入 Quanta 时，团队可用统一余额管理多模型调用；前端不应保存平台密钥，也不应决定用户额度。
02 · 第二步：选择支持请求体的流式读取
原生事件源适合简单订阅，但不方便发送生成任务所需的请求体和自定义鉴权头。聊天页面可采用支持流式响应的请求接口，由浏览器读取响应体。后端需声明事件流类型，并关闭代理缓冲，避免增量结果被攒成整段。
03 · 第三步：按事件边界解析，而非按网络块解析
网络块可能截断汉字，也可能装入多个事件。先用流式文本解码器处理字节，再将文本放入缓冲区，按空行提取完整事件；兼容不同换行形式，合并多行数据，忽略心跳注释，最后解析事件载荷。
04 · 第四步：明确结束状态并合并渲染
区分连接中、生成中、已完成、已取消和失败。收到响应头不代表生成成功，连接关闭也不一定代表完整结束。依据上游协议识别结束信号；增量内容先暂存，再按浏览器绘制节奏合并更新，避免每个片段都触发页面重排。
05 · 第五步：让停止按钮取消上游生成
用户停止或离开页面时，浏览器应取消请求，后端继续向上游传递取消信号。只停止显示并不能停止消耗。断流后不要自动重发生成任务：除非服务明确支持续传或幂等，否则可能重复生成、重复计费。
06 · 第六步：分别记录体验和真实消耗
记录首段内容耗时、总耗时、活跃连接数和失败原因。Quanta 按实际令牌计量，缓存写入与读取分别计价；页面显示的字符数不能代替账单。建议先开通 Quanta 账户，用小额真实任务核对用量，再制定并发和预算限制。
07 · 第七步：用故障场景验收灰度发布
- › 模拟慢网、半包、多事件粘连和连接中断。
- › 确认取消能释放连接，代理超时不会截断正常长任务。
- › 先开放少量流量，观察内存、排队和费用，再扩大范围。
验收标准不是文字会动，而是每条流都能正确结束、取消和核账。