Go context 超时取消为什么重要：从接口耗时到 goroutine 泄漏的治理思路

很多 Go 新手第一次接触 context，会把它当成“传 trace id 的参数”。但在服务端代码里，context 更核心的价值是把取消、超时和请求范围传下去：入口超时后，下游数据库请求、RPC 调用、后台任务都应该尽快停下，避免继续占用 goroutine、连接和内存。

根据 Go 官方 context 包文档，Context 会携带截止时间、取消信号和请求范围值；从 WithCancel、WithDeadline、WithTimeout 派生出的 context 会返回 CancelFunc，调用它可以释放相关资源。官方 Go Concurrency Patterns: Context 也强调，一个请求衍生出的 goroutine 需要能在请求取消时一起退出。

趋势信号：接口都需要可取消链路

现在的 Go 服务很少只是单机函数调用。一个 HTTP 请求可能会访问 Redis、MySQL、对象存储、第三方接口，还可能启动几个 goroutine 做并发查询。如果入口已经超时，后面的工作还继续跑，用户看不到结果，服务却还在付资源成本。

这就是 context 越来越重要的原因：它不是为了让代码多一个参数，而是让请求链路有统一的“停止信号”。入口取消后，所有认真接收 ctx 的下游代码都能知道该退出了。

解决的问题：超时不是只给用户看

很多系统里的超时只停在网关或 HTTP 层：用户收到 504，服务端内部的查询、重试、任务还在继续。这样会带来几个问题：

• goroutine 泄漏：等待通道、网络或锁的 goroutine 没有退出条件。
• 连接占用：数据库或 RPC 请求继续等待，连接池被慢请求拖住。
• 重复工作：调用方已经放弃，后台还在计算无用结果。
• 排查困难：日志只看到入口超时，看不到下游何时停下。

最小写法是给入口设置超时，并保证 cancel 被调用：

func handler(w http.ResponseWriter, r *http.Request) {
    ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
    defer cancel()

    result, err := queryUserProfile(ctx, r.URL.Query().Get("id"))
    if err != nil {
        if errors.Is(err, context.DeadlineExceeded) {
            http.Error(w, "request timeout", http.StatusGatewayTimeout)
            return
        }
        http.Error(w, "query failed", http.StatusInternalServerError)
        return
    }

    writeJSON(w, result)
}

这里的重点不是“2 秒”这个数字，而是入口拿到 ctx 后继续传给下游，让取消信号能走完整条链路。

受益角色：接口、任务和下游调用都更稳

context 最直接受益的是接口服务，但它不只服务 HTTP。

• HTTP 接口：用户断开连接或入口超时后，下游请求可以尽快停止。
• 数据库访问：使用支持 context 的查询、写入和事务方法，团队可以统一约定“带 Context 后缀”的数据库调用方式。
• 后台任务：任务关闭、发布回滚或队列停止时，可以通过 ctx.Done() 退出循环。
• 并发查询：多个 goroutine 并发查数据时，一个失败或入口取消，其他分支也能收到停止信号。

后台循环通常要显式监听 ctx.Done()：

func worker(ctx context.Context, jobs 

风险边界：context 不是万能状态袋

使用 context 也容易走偏。常见风险有三类：

• 忘记调用 cancel：WithTimeout 返回的 CancelFunc 应及时调用，通常用 defer cancel()。
• 只在入口创建，不往下传：如果下游函数没有接收 ctx，取消信号就断了。
• 把业务参数塞进 context：context.Value 适合请求范围元数据，不适合替代函数参数。

一个简单判断是：如果某个值影响业务逻辑分支，优先做成显式参数；如果它是 trace id、登录用户、租户标识等请求范围信息，才考虑放进 context。

采用路径：从入口超时到下游取消

把 context 做好，不需要一次重构全部代码。可以按下面路径推进：

1. 入口先统一：HTTP、定时任务、队列消费者都明确根 context 和超时。
2. 函数签名前置 ctx：团队约定 func Do(ctx context.Context, ...)，让取消信号优先可见。
3. 下游方法接入：数据库、RPC、缓存、外部接口都使用支持 context 的调用方式。
4. 错误分类：区分 context.Canceled、context.DeadlineExceeded 和普通业务错误。
5. 补测试：用很短 timeout 验证函数是否能及时退出。

观察指标：怎么判断治理有效

context 治理不是“代码里出现了 ctx”就算完成，应该看指标是否变好：

• P95/P99 耗时：超时请求是否更快结束，而不是拖到连接池耗尽。
• goroutine 数：压测后是否能回落到稳定区间。
• 下游超时率：数据库、RPC、外部接口的超时错误是否可分类。
• 连接池等待：入口取消后，连接占用是否减少。
• 日志链路：一次取消是否能从入口追到下游退出点。

如果这些指标没有变化，只是把 ctx 参数一路传下去，说明代码还没有真正响应取消信号。重点检查最慢的下游调用和最长生命周期的 goroutine。

总结

Go 的 context 解决的是链路级生命周期问题：什么时候该停、谁来通知、下游如何退出。它不能替你设计业务状态，也不应该承载大量业务参数；但在接口超时、并发查询、后台任务和服务关闭场景里，它是减少无效工作和 goroutine 泄漏的关键工具。实践时记住三件事：入口设置边界，函数持续传递，下游真正监听取消。