Go context.WithCancel 为什么要主动调用 cancel：资源释放与请求收尾

线上接口已经返回 200，但进程里的后台 goroutine 数量还在缓慢上涨，通常不是“context 自动失效”这么简单。用 context.WithCancel 创建子上下文时，真正负责结束这条取消链的是返回的 cancel 函数；不调用它，定时器、父上下文注册关系以及等待取消的工作协程都可能迟迟不能收尾。

先看清取消链到底管理什么

context.WithCancel(parent) 返回一对 ctx 和 cancel。前者把取消信号传给下游，后者负责把信号沿子树传播出去。它不是一个万能的资源管理器：它能让监听 Done() 的代码醒来，却不会自动关闭文件、数据库 rows 或业务层创建的 worker。

可以把责任边界记成一句话：创建子上下文的函数拥有取消权，接收 ctx 的函数拥有响应取消的责任。两边都做对，退出才是完整的。

HTTP 请求中用 defer 保住第一道收尾

最常见的写法是在 handler 或 service 入口创建带取消能力的子上下文，并立刻注册 defer cancel()。这样无论后面的校验、查询或返回路径怎么结束，函数退出时都会发出取消信号。

func loadProfile(parent context.Context, uid int64) (Profile, error) {
    ctx, cancel := context.WithCancel(parent)
    defer cancel()

    profile, err := queryProfile(ctx, uid)
    if err != nil {
        return Profile{}, err
    }
    return profile, nil
}

这里的 defer 不是为了“防止超时”，而是为了覆盖成功返回、查询报错和中途新增分支三种路径。若还要限制时长，可以使用 context.WithTimeout；它同样应该保留返回的取消函数并调用。

后台 goroutine 必须真正消费 Done

只在调用方写 cancel() 还不够。后台任务需要把取消信号放进自己的循环，否则它虽然拥有 ctx，却不会结束。

func watch(ctx context.Context, done chan

验证时不要只看 cancel() 是否执行。更可靠的信号是 done 被关闭、ticker 停止，以及任务内部记录了 ctx.Err()。如果 refreshCache 自己还调用了阻塞 API，也要把同一个 ctx 继续传下去。

父子上下文的范围与常见误区

子上下文的取消不会反向取消父上下文。一个请求可以派生多个子任务，某个子任务失败时调用自己的 cancel，只会终止这一支；如果调用的是请求根部的取消函数，所有下游都会收到信号。

另一个容易混淆的点是把 context.Background() 传进每个函数。这样做会切断请求的取消链，客户端断开或上层超时时，下游仍然继续工作。入口可以使用 Background 创建根，但业务函数应优先接收并透传已有 ctx。

用测试确认取消真的到达末端

测试不必等待 goroutine 自己“应该会退出”。让任务写出明确完成信号，并在测试中设置有限等待窗口：

ctx, cancel := context.WithCancel(context.Background())
done := make(chan struct{})
go watch(ctx, done)

cancel()
select {
case 

如果测试偶发超时，先检查 worker 是否卡在没有 ctx 的阻塞调用，再检查是否漏掉了 ticker、rows 或连接的关闭逻辑。不要仅仅把等待时间从 1 秒改成 10 秒。

三个需要记住的边界

• 取消不是关闭：文件、rows、连接等资源仍由创建它们的代码显式关闭。
• 取消不是抢占：正在执行的普通 CPU 计算不会被强行打断，代码要主动检查 ctx。
• 取消函数可以重复调用：它是幂等的，但通常只需由拥有它的那一层统一负责。

相关问题

调用 cancel 后 ctx.Err() 一定是 context.Canceled 吗？

主动调用 cancel 通常得到 context.Canceled；如果先触发了超时或截止时间，则可能是 context.DeadlineExceeded。下游应检查错误类型，而不是只判断字符串。

函数只读 ctx 不启动 goroutine，还要调用 cancel 吗？

如果函数创建了 WithCancel、WithTimeout 或 WithDeadline，就应负责调用返回的 cancel。若只是接收上游传入的 ctx，则不应尝试关闭它。

为什么 worker 收到 Done 仍然没有退出？

常见原因是 worker 卡在不支持 ctx 的阻塞调用，或 select 外还有无法返回的清理逻辑。把 ctx 传到数据库、HTTP 客户端等下游，并为清理设置可观察的完成信号。

把 cancel 看作取消树的开关，把 Done 看作下游必须接通的回路，再单独管理业务资源，Go 服务的请求收尾就会清楚很多。