一句话定义：流式（Streaming）输出过程中，连接因网络抖动、超时、客户端取消或服务端异常而断开，客户端已经收到并渲染了一部分 AI 词典：Token">Token（词元），却始终没等到正常结束信号——这就是"半截响应"。
它为什么一定会存在
流式输出是把一次生成拆成很多小包，边算边发（常见实现是 SSE，Server-Sent Events）。正常结束时，服务端会补一个终止标记，比如 finish_reason: stop 或一个 [DONE]。中断时这个标记不会来，客户端只能从"连接没了"反推出"话没说完"。
打个比方：点了一锅现煮的粥，服务员一碗一碗往上端。端到第三碗时人不见了。你面前确实有粥，但这顿饭没上完，而且没人告诉你"上完了"。
断在第三个字 vs 断在第三百个字
这两个故障在监控上看是同一类，在产品上完全是两回事。
- 断在第三个字：首字延迟（TTFT，Time To First Token）之后立刻掉线。用户几乎没读到东西，正确做法是静默重试，别让屏幕上闪半句话又消失。
- 断在第三百个字：用户已经读进去了，甚至已经照着做了。这时不能静默重试——会重复输出、浪费额度，用户还得自己找接缝。该做的是保留原文、标一个"已中断 / 继续生成"。
真正的分界线是：这段内容有没有"交给用户"。交出去了，就得当成已发生的事实来处理。
三个"算不算"
用户看到的算不算数？ 算"未提交"。UI 状态机至少要区分 streaming / interrupted / completed 三态。半截内容如果被原样写进会话历史，下一轮模型会把它当既定前提继续推理，错误就被固化了——这叫上下文污染，比直接报错更难查。
计费算不算数？ 通常按实际消耗的输入与已输出 Token 计。各家对失败请求是否返还策略不同，涉及钱的部分以官方计费文档为准。工程上要做的是：请求带 trace id，中断时能记录"已收到第 N 个 chunk"，出账时对得上。
重试算不算重复？ 不带幂等键（Idempotency-Key）的重试可能生成两遍、计两遍。这是工程事故的高发区。
和相邻概念的区别
| 现象 | 结束信号 | 内容完整度 | 该怎么做 |
|---|---|---|---|
| 正常结束 | stop | 完整 | 落库 |
| 触顶截断 | length（达到 max_tokens 或上下文上限） | 不完整但正常 | 提示续写 |
| 流式中断 | 无 | 未知 | 标记 + 幂等重试 |
注意"截断"和"中断"不是一回事：截断是系统主动喊停，你收得到通知；中断是对方失联，你只能猜。
对从业者和普通人的意义
做产品的：把"中断"当成一等公民设计，别等线上出事故才补。做后端的：把每个 chunk 的序号写进日志，对账和排查都靠它。
普通用户：看到回答戛然而止、又没有"已中断"提示时，别把它当完整答案用。半截的代码、半截的数字、半截的结论，比没有结论更危险——因为它看起来像是说完了。