Go 接入模型流式输出后客户端断开怎么办：取消上游请求并清理 goroutine

一个 Go 网关把大模型的流式输出转发给浏览器后，最容易被忽略的故障不是模型侧报错，而是用户点了刷新：浏览器已经断开连接，服务端的读取循环和上游 HTTP 请求却还在后台继续跑。时间一长，连接数、goroutine 数和模型调用量同步往上攀升，日志里只能搜到零散的超时报错，完全找不到根因。

先看断连现场：浏览器停了，上游为什么还在跑

故障通常出现在一个类似 /api/chat/stream 的接口。网关收到请求后，向模型接口发起带 stream=true 的 HTTP 请求，再把上游返回的 SSE 事件逐段写给浏览器。用户关闭页面后，网关这一侧的响应已经没有接收者，如果代码没有把取消信号传给上游，读取循环仍会阻塞在等待下一段数据的状态上。

现场可以先做一个非常简单的复现：打开浏览器开发者工具，发起一条需要持续输出的请求，等首段文字出现后立刻刷新页面。此时记录三组指标：仍处于读取状态的请求数、服务进程 goroutine 数、上游模型请求数。修复前，浏览器侧的请求数会立刻下降，上游请求数却要慢几秒甚至更久才回落，这就是“下游断了、上游没停”的直接证据。

快速判断：把取消信号和读取循环对上

Go 的 net/http 文档已经给出了关键语义：服务端请求的 context 会在客户端连接关闭时被自动取消。问题从来不是有没有取消信号，而是业务代码有没有全程正确使用这个 context。

常见的错误写法是从 context.Background() 重新创建上游请求。这么做会把新请求的生命周期和浏览器的请求完全割裂开，哪怕浏览器已经离开页面，上游调用也收不到任何停止通知。另一个容易漏的点是只检查写响应的错误：写失败确实能发现断连，但如果读取上游数据的 goroutine 没有退出，相关资源仍然会留在半开状态没法回收。

func streamHandler(w http.ResponseWriter, r *http.Request) {
    upstreamReq, err := http.NewRequestWithContext(
        r.Context(),
        http.MethodPost,
        "https://api.example.com/v1/responses",
        bytes.NewReader(payload),
    )
    if err != nil {
        http.Error(w, "build upstream request failed", http.StatusInternalServerError)
        return
    }

    resp, err := http.DefaultClient.Do(upstreamReq)
    if err != nil {
        if errors.Is(r.Context().Err(), context.Canceled) {
            return
        }
        http.Error(w, "upstream request failed", http.StatusBadGateway)
        return
    }
    defer resp.Body.Close()

    if err := runStream(r.Context(), w, resp.Body); err != nil {
        if errors.Is(r.Context().Err(), context.Canceled) {
            return
        }
        log.Printf("stream relay failed: %v", err)
    }
}

这里有三个校验点：请求用的是 r.Context()，响应体有明确的 Close，读取函数也传入了同一个 context。三者缺任意一个，断连后的资源回收都可能变慢。

修复核心：让 SSE 读取循环在断连时马上退出

上游响应可以按 SSE 的空行分隔事件。示例只聚焦生命周期管理，不绑定任何第三方 SDK 的事件结构：每读到一行就转发给下游，发现 context 已取消就直接停止下一轮读取。实际项目里还需要额外处理事件类型、错误事件和结束事件的分支。

func runStream(ctx context.Context, w http.ResponseWriter, body io.Reader) error {
    flusher, ok := w.(http.Flusher)
    if !ok {
        return errors.New("stream response is not flushable")
    }

    scanner := bufio.NewScanner(body)
    scanner.Buffer(make([]byte, 4096), 1024*1024)
    for scanner.Scan() {
        select {
        case 

这段代码没法替代底层网络的取消逻辑。真正让上游读取中断的是 NewRequestWithContext 绑定的请求 context；循环中的 select 则是让业务层在已经拿到一段数据时及时收尾。响应体的关闭由外层 defer 兜底，避免某个异常分支忘记释放连接。

处理步骤：先补观测，再做小流量切换

给每次转发记录四个状态

不要只笼统记录“请求成功”。建议在同一条日志里保留请求 ID、上游响应状态、结束原因和持续时间。结束原因至少分成 completed、client_canceled、upstream_error 三类。这样就能把用户主动刷新和真正的上游故障分开统计，不会混在一起算错误率。

用可控客户端制造断连场景

测试环境里可以让客户端在收到首个事件后主动关闭连接，连续跑几十次压测，再静置观察五分钟。重点看 goroutine 数是否回到基线、HTTP 连接池是否正常复用、上游请求数是否跟着下游断连同步下降。只看接口返回码没有意义，因为断连时浏览器根本拿不到最终的响应状态。

保留上游超时作为第二道边界

context 解决的是上下游生命周期联动的问题，不等于永远不需要配置超时。可以在入站 context 上派生一个有上限的超时 context，给单次模型调用设置业务允许的最长时间；客户端提前断开时，更早触发的取消仍然优先执行。

回滚路径：如果新逻辑让流式响应提前结束

上线后如果出现正常请求也频繁收到 context canceled，先不要直接把取消检查删掉。第一步核对代理层的空闲超时、响应缓冲和 SSE 相关配置；第二步把新版本切回小流量前的构建，同时保留全量断连日志；第三步用一个固定的短文本请求确认是代理层截断，还是应用把 context 错误地传进了其他后台任务。

尤其不要把入站 context 直接传给需要在请求结束后继续运行的持久任务。如果要做异步落库、计费或写审计记录，应该先复制必要字段再使用独立的任务生命周期；流式转发本身的逻辑则必须跟随用户请求的生命周期同步结束。

告警确认：取消数量高不一定是故障

流式接口场景下的用户刷新、切换会话和移动网络抖动都会主动制造取消事件。告警更适合关注“取消后仍未回收”的组合信号，例如 client_canceled 后五分钟仍持续增加的活跃上游请求、连接池等待时间、goroutine 数，以及上游返回的超时比例。

修复生效时，断连峰值会先上升，随后上游请求和 goroutine 会在很短时间内回落；如果只有入站请求数下降，其他指标曲线完全不动，说明取消链路仍然断在某一层逻辑里没打通。

常见问题

客户端断开后，Go 一定会立刻终止上游请求吗？

不一定。只有上游请求绑定了入站 context，并且读取链路没有被其他独立 context 隔离，取消才会沿链路完整传播。

为什么只判断 ResponseWriter 写入错误还不够？

写入错误只能说明下游写失败，不能保证读取上游的循环和响应体已经结束。还是要绑定 context、退出读取循环并关闭响应体才能彻底释放资源。

可以把所有 context canceled 都记成错误吗？

不建议。客户端主动断连通常是正常业务事件，可以降级为信息日志；只有取消后资源不回落、异常比例持续升高时才需要升级告警。

流式响应为什么要调用 Flush？

Flush 让已经读到的片段尽快交给客户端。它不会负责取消上游请求，生命周期控制仍然要依靠请求 context 和响应体关闭。

复盘清单：把一次断连修复变成门禁规则

• 入站 Request.Context() 是否贯穿传递到模型 HTTP 请求？
• 所有响应体是否都有明确的关闭路径？
• 断连后读取循环、上游请求和 goroutine 是否在可接受时间内回落？
• 取消、上游错误和完整结束三种场景是否能从日志里清晰区分？
• 异步任务是否错误复用了已经结束的入站 context？

流式输出的稳定性不只取决于模型返回速度，更取决于每一层逻辑是否尊重请求的完整生命周期。把断连当成一条正常信号处理，网关才不会在用户已经离开后继续替他消耗连接和调用额度。