回答说到一半就停：流式响应被中途掐断的排查顺序

先理解流式传输为什么特别脆弱

普通的网页请求是一次性的：发出去、等一会儿、一次性收到完整回答、连接关闭。整个过程通常在几秒内结束，中间没有空闲。

AI 对话和补全用的是另一种形式：连接建立之后长时间保持打开，服务端一边生成一边把内容分片推过来。据 W3C《Server-Sent Events》规范，这类事件流建立在一条持续打开的连接之上，服务端按事件为单位陆续推送数据，客户端在连接断开后依据最后收到的事件标识决定如何续接。

脆弱就来自「长时间保持打开」这个特征。一条只存活两秒的连接，几乎不给中间环节任何介入的机会；一条要保持三十秒甚至几分钟的连接，会依次经过你的设备、家里的路由器、运营商的设备、若干中间网络，其中任何一个环节只要认为这条连接「太久没动静」或者「不该存在这么久」，都可以单方面把它掐掉。而掐掉的方式往往很干净——不发错误，直接不再转发，于是两端都以为对方还在。

空闲超时：最常见的那一类

很多网络设备会为经过它的连接维护一张表，记录每条连接的状态和最后活动时间。表的容量有限，所以设备需要清理：超过一定时间没有数据往来的条目会被丢弃，对应的连接随之失效。

这个机制平时完全无害，因为普通连接活得很短。但流式响应有一个特点会正好撞上它：服务端在开始生成之前，可能需要相当长的思考时间。请求已经发出、连接已经建立，然后是一段完全没有数据往来的等待。如果这段等待超过了中间某个设备的空闲阈值，连接在第一个字还没吐出来之前就已经被清理掉了。

它的典型表现是：短回答一切正常，长回答或者需要长时间思考的复杂问题总是失败，而且失败的时间点很接近，像有个固定的秒数在那里。如果你观察到这种规律性，空闲超时的可能性很大。

缓冲：看起来是断了，其实是没吐出来

还有一种情况完全不是断连，但表现和断连难以区分。

某些中间环节会对经过的内容做缓冲——先攒到一定量再一起转发，而不是收到一点就转发一点。这对普通网页是优化，对流式响应是灾难：服务端一个字一个字地推，中间环节一直攒着不发，你这边看到的就是长时间没有任何输出。等攒够了一次性全部到达，又变成整段文字瞬间出现。

怎么区分它和真断连：真断连之后再等也不会有任何东西过来；缓冲只是延迟，最终会到。所以遇到「停住」时不要立刻刷新，先耐心等上一段时间——如果后面内容成批出现，那是缓冲；如果一直什么都没有，才是断了。这一条会直接影响你下一步该查什么。

怎么定位是哪一层

第一层，换网络。同一个请求，分别在家里的宽带和手机热点上各试几次。如果只在其中一个网络上出问题，那问题在那个网络的路径上，和你的设备、和服务端都无关。这是最快的分层手段，也最容易被跳过。

第二层，换客户端。用网页版和用命令行工具或者编辑器插件分别试。这三类程序的连接配置往往是独立的，如果只有其中一个有问题，方向就落在那个程序自己的设置上，不必去查网络。

第三层，看失败位置的规律。每次都停在差不多的时间点，指向超时类原因；停的位置完全随机，更像链路质量问题；只在特别长的回答上出现，指向总时长限制。

第四层，短问题对照。问一个能在两三秒内答完的简单问题。如果短问题百分之百正常、长问题稳定失败，基本可以确定是时长相关的机制，而不是连通性。

能做和不能做的

能做的：把需要长时间生成的任务拆成几个短请求，让每一条连接都活得足够短，绕开空闲超时；在支持的客户端里把请求超时设置调高，避免客户端自己先放弃；换一条中间环节更少的路径，减少可能掐断连接的设备数量。

不能做的：你无法让运营商设备或者中间网络改变它们的连接表清理策略，也无法让某个中间环节停止缓冲。这两件事不在你的控制范围内，唯一可行的方向是减少经过的环节，或者让连接不要长到触发它们。

如果换网络这一步指向了路径问题，一条中间环节更可控的通道通常是最直接的处理方式。