Go 服务请求超时后 goroutine 还在跑怎么办？context 取消与排查清单

接口已经在网关处返回超时，服务进程里的 goroutine 却还在等数据库、等网络或等一个永远收不到结果的 channel，这类问题最怕“表面恢复了，资源没有回收”。在 Go 里，超时本身不会自动终止所有后台工作；真正能让调用链正常收口的是把同一个 context.Context 继续往下传，并在创建派生 Context 的地方及时调用对应的取消函数。

先确认是不是“请求结束，后台没收口”

值班时遇到的组合告警信号很明确：5xx 错误或超时占比先上升，随后 goroutine 数量持续缓慢走高；数据库连接池的等待时间不断拉长，但业务日志里已经能看到请求向客户端返回的记录。这时候别着急把服务端超时时间调大。先把同一条请求的 trace 或者 request id 串起来，确认接口返回后是否还有对应的 SQL、RPC 或重试日志继续输出。

Go 官方 context 包文档明确说明，WithCancel、WithDeadline 和 WithTimeout 返回的 CancelFunc 都应该被调用；不主动调用的话，子 Context 会一直保留到父 Context 被取消为止。文档也提示 go vet 可以用来排查取消函数是否覆盖了所有控制分支。

用两个检查点快速缩小排查范围

第一步，找一个耗时两三分钟的慢请求样本，在接口返回超时的前后分别抓一次 goroutine profile。重点不用看总数量，而是确认相同栈帧是否在大量 goroutine 里重复出现：比如大量 goroutine 停在网络读取、数据库等待，或是一个没有发送方的 channel 接收逻辑上。第二步，顺着请求入口函数检查 Context 有没有被中途替换。下面几种写法最容易把取消信号弄丢：

• 处理请求时已经拿到了 r.Context()，调用 service 层逻辑的时候却传入了 context.Background()。
• service 层创建超时 Context 后，只在成功分支调用 cancel()，错误分支直接提前返回跳过了取消逻辑。
• 数据库或 HTTP 客户端已经提供了带 Context 的方法，代码里却还在使用不带 Context 的旧版本方法。
• 新起的 goroutine 内部只等待任务 channel，没有同时监听 ctx.Done() 的取消信号。

排查时可以先运行 go vet ./...。它不是专门的泄漏检测工具，但能提前指出不少明显没有走到取消函数的控制路径。再配合压测或是小流量灰度，观察超时结束后的30到60秒内，goroutine 数量和连接池等待数能不能回到平时的正常波动区间。

创建超时 Context 后，取消函数要就近释放

最稳妥的写法是在创建 Context 的下一行就安排 defer cancel()。这不是多余动作：哪怕业务任务提前执行成功，主动调用取消函数也能尽早释放关联资源；就算父请求已经先一步结束，重复调用取消函数也不会引发任何问题。

func loadProfile(parent context.Context, client *http.Client, url string) error {
	ctx, cancel := context.WithTimeout(parent, 2*time.Second)
	defer cancel()

	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return err
	}

	resp, err := client.Do(req)
	if err != nil {
		return err
	}
	defer resp.Body.Close()

	if resp.StatusCode >= http.StatusInternalServerError {
		return fmt.Errorf("profile service status: %s", resp.Status)
	}
	return nil
}

这里有两个核心点。第一，派生 Context 的父节点必须是调用方传下来的 parent，这样客户端断开连接、网关设置的截止时间和服务内部预留的处理时长能共同生效。第二，http.NewRequestWithContext 会把取消信号真正传递给网络调用；只创建 ctx 却没把它传给对应的请求，超时规则完全不会影响那次网络等待的逻辑。

让数据库、worker 和重试逻辑都能收到取消信号

调用链里最容易遗漏的场景是“接口已经携带有效 Context，异步工作却私自开新协程跑完全独立的逻辑”。Go 的 Context 设计初衷就是跨 API 边界传递截止时间和取消信号，相关说明可以参考 Go 官方博客的 Context 介绍。下游函数的第一个参数统一保留为 context.Context，后续做代码评审的时候很容易就能发现 Context 传递断链的问题。

func consume(ctx context.Context, jobs 

数据库调用也不能完全依赖驱动自身的超时配置。优先使用携带 Context 的查询、事务和写入接口，才能把上游的取消信号同步传入数据库操作逻辑。Go 官方的取消数据库操作指南，也推荐用携带超时 Context 的方式执行查询。第三方 RPC、消息队列和对象存储客户端，要提前确认它们是否提供 Context 版本的方法；如果没有对应方法，至少要确认连接和等待逻辑能被自定义的 deadline 规则管控。

别把“新开 goroutine”当成绕过超时的方案

部分代码为了让接口快速返回，会把耗时操作丢进新的 goroutine，再用 select 等待结果或者设置超时。这种写法只能让当前请求先返回客户端，不会自动终止被丢出去的后台任务。只要 goroutine 内部没有校验 ctx.Done() 的取消状态，它依然会一直占用连接、内存和下游服务的请求配额。

更需要留意的错误写法是把 Context 存进生命周期很长的结构体，或是为了图方便在深层函数里直接改用 context.Background()。第一种写法会把请求的生命周期搞模糊，第二种写法直接切断了整条取消传递链。context 包文档里也明确了对应的使用约定：Context 要显式传递，不能直接作为结构体字段存储。

线上故障处理顺序：先止损，再修复代码

1. 固定现场证据。保留超时窗口内的 trace 数据、错误日志、goroutine profile 和连接池指标，先定位是哪个下游依赖在持续等待。
2. 缩小影响入口。对风险较高的接口临时降低并发阈值，或是关掉非必要的后台分支逻辑，避免新的请求积压持续放大故障影响。
3. 补全取消传递链。从 handler 层到 service、repository、client 层逐层传递同一条 Context；创建派生 Context 的位置就近调用对应的取消函数。
4. 安全回退配置。如果改动涉及重试策略或是批量消费逻辑，先回退到上一个经过验证的限流规则、重试间隔和并发阈值，不要在故障处理阶段同时调大超时时间和并发数。
5. 灰度验证效果。在小流量场景下制造一次可控的超时请求，确认接口返回后 goroutine 数量、连接等待数和重试计数都能正常回落。

这里说的回退不是把所有接口的超时时间都拉得很长。超时设置过长会延迟失败反馈，也会让资源占用的持续时间被拉得更久。线上故障处理时优先守住问题接口的并发和重试上限，再通过 profile 找到真正没有退出的调用点，效率会高很多。

告警不要只盯着5xx错误，还要监控“超时后的资源回落”

实用的告警规则至少要覆盖三层指标：请求超时占比、goroutine 数量的上涨斜率、下游连接等待队列长度。单独出现少量5xx错误大概率是网络瞬时抖动；如果请求超时之后资源占用完全不回落，才是典型的取消传递链失效问题。告警描述里最好附上最近的调用栈摘要、异常接口名和对应的依赖名，避免值班人员收到告警后只能看到一个笼统的“服务变慢”提示。

故障复盘的时候可以把所有下游依赖整理成检查清单：是否支持传入 Context、是否自带独立的超时截止时间、收到取消信号后会不会主动释放连接、重试逻辑能不能正常停止、有没有对应可观测的等待指标。后续接入新的 SDK 或是开发后台任务的时候，对照这份清单校验，比事后临时补个超时参数要稳妥很多。

常见问题

调用 cancel() 会不会把父请求也顺带取消？

不会。取消函数只会影响本次调用生成的派生 Context 以及它下面的所有子节点，不会反向作用到上层的父 Context。

已经给 HTTP 客户端设置了超时，还有必要单独传递 Context 吗？

还是要传。客户端自带的超时配置通常只覆盖网络层面，Context 能把取消意图同步传递给数据库调用、后台 worker、RPC 请求和业务自定义的函数调用链。

明明已经用了 WithTimeout，goroutine 为什么还是退不出来？

最常见的原因是 goroutine 内部没有监听 ctx.Done() 的信号，或是内部调用没有把这个 Context 传进去。排查所有阻塞点和重试等待逻辑就能找到问题。

能不能把 Context 放到全局变量里，省得每层都手动传参？

不建议这么做。请求级别的 Context 有明确的生命周期，显式作为函数的第一个参数传递，才能让取消逻辑的边界清晰，后续代码评审也很容易发现异常。

修复完之后怎么证明完全没有残留的后台任务？

在测试环境或是小流量灰度区制造可控的超时场景，对比请求结束前后的 goroutine profile、数据库连接等待数和重试计数，确认所有指标都能在合理时间内回到平时的基准线附近。

把超时当成一条需要贯穿整条调用链的停止信号，排查思路就会清晰很多：请求入口负责分配处理时长，业务代码负责正常传递信号，下游逻辑负责响应信号，监控数据负责验证资源真的被正常回收。