OpenAI 兼容接口的流式输出 SSE 接入方法
很多人接流式输出时，以为只要把 stream 打开就结束了。真正麻烦的是如何稳定解析事件流、实时渲染文本，以及在中断、取消和异常结束时把状态收干净。
从流式响应解析、前端增量渲染到中断收尾，做好大模型 streaming 体验。
适合谁看
适合正在接第三方模型 API、做兼容层、排线上报错的开发者和团队。
这篇会回答
• 先把 SSE 数据边界处理正确
• 前端增量渲染要考虑中断和收尾
• 服务端要区分慢流和坏流
这篇在专题里的位置
围绕 401、402、429、503、504、流式输出、兼容接口、Key 管理和网关接入，先解决“能不能稳定跑起来”。
Claude API 接入清单
从模型选择、请求结构到限流与日志，梳理一份更稳的接入流程。
Claude acceleration limits 是什么，为什么刚放量就 429
根据 Anthropic 官方文档，拆开讲 acceleration limits、短时间突发流量和 rate limit 的区别，方便你判断为什么总量没超、请求还是被卡。
Claude API 401 authentication_error 怎么排查
根据 Anthropic 官方错误文档和 API 接入说明，拆开讲 Console Key、请求头、版本头和代理转发问题，方便你快速定位 Claude API 的 401 authentication_error。
先把 SSE 数据边界处理正确
流式输出最容易出错的不是模型本身，而是你自己对 chunk 的处理方式。事件流可能分段、断行，也可能在网络抖动时留下半截数据。
因此解析时要基于事件边界和缓冲区累积，而不是简单按每次读取到的字符串直接拼接。
前端增量渲染要考虑中断和收尾
真正好的流式体验，不只是字一个个出现，还要在结束时明确告诉用户任务已完成，或者在异常中断时给出可恢复状态。
如果不处理 done 事件、abort 信号和错误状态，页面看起来像卡住，用户会误以为模型没返回。
服务端要区分慢流和坏流
有些流式请求只是输出慢，但仍在正常推进；有些则是前面发了几段数据，后面彻底断流。
监控时要区分首包耗时、单 chunk 间隔和总完成率，这样才能判断问题在模型、网络还是你自己的代理层。
常见问题
是不是所有场景都应该开流式输出？
不是。短回答、结构化 JSON 和后端批处理任务未必适合流式，只有用户真的需要边看边等时，streaming 的价值才明显。
流式输出中途断了怎么办？
要先保留已经收到的内容，再提示用户重试、继续生成或切换备用链路，而不是直接把整段结果清空。
继续沿着这条主线看
这部分不再重新给你一堆大卡片，而是直接把下一步阅读顺序列出来，方便继续往下走。
Claude API 接入清单
从模型选择、请求结构到限流与日志，梳理一份更稳的接入流程。
Claude acceleration limits 是什么，为什么刚放量就 429
根据 Anthropic 官方文档，拆开讲 acceleration limits、短时间突发流量和 rate limit 的区别，方便你判断为什么总量没超、请求还是被卡。
Claude API 401 authentication_error 怎么排查
根据 Anthropic 官方错误文档和 API 接入说明，拆开讲 Console Key、请求头、版本头和代理转发问题，方便你快速定位 Claude API 的 401 authentication_error。
Claude API 529 overloaded 怎么处理
根据 Anthropic 官方错误文档、Rate Limits 和状态页，拆开讲 529 overloaded 与 429、401 的区别，以及线上更稳的重试、降级和观察路径。