流式输出断了怎么办：断流、超时与补全
流式返回（SSE）在体验上明显更好，但把错误处理放大了：非流式请求失败就是失败，流式请求失败可能是「吐了一半」。这一半要不要保留，决定了你的重试策略。
约定一：首字超时与整体超时分开设
首字超时衡量的是上游排队的健康度，一般设短（几秒）；整体超时衡量的是生成长度，按业务需要设。把两个超时合成一个，会让你分不清是上游慢还是内容长。
约定二：断流后按「重跑整轮」处理
已经吐出的内容可以作为占位显示给用户，但不能作为下一次请求的上下文重发——那会把重复内容喂回模型，产生双倍输入。稳妥做法是重跑整轮，前端用同一个消息槽位替换。
约定三：区分「可重试」与「不该重试」
429 与 5xx 可重试；4xx 里的参数错误不该重试，重试只会重复失败并计费。判定逻辑放在网关客户端里，别让每个业务各写一遍。
约定四：把流式状态上报
至少记录三个时间点：请求发出、首字到达、流结束。三个时间点能解释绝大多数「用户说慢」的工单。
落地清单
- 两类超时分别配置。
- 断流一律整轮重跑，不复用半截内容。
- 429/5xx 才重试，4xx 直接失败。
- 三个时间点写进日志。