Go context 没有调用 cancel 为什么会拖住资源释放

在 Go 里，context.WithCancel、context.WithTimeout 和 context.WithDeadline 都会返回一个派生上下文与一个 cancel 函数。忘记调用它，通常不会让业务立刻报错，却会让定时器、父子上下文关系和等待中的协作更晚结束。最稳妥的判断是：谁创建派生上下文，谁就负责在这次操作结束后调用 cancel。

超时只是兜底的结束条件，不是省略 cancel 的理由。创建派生上下文后，先安排 defer cancel()，再把它传给真正需要取消信号的下游操作。

创建派生上下文后，cancel 由谁负责

可以把 context 看成一棵取消树：请求或任务是父节点，WithTimeout 产生子节点。子节点的 Done() 会在父节点取消、调用子节点的 cancel，或截止时间到达时关闭。创建者最清楚这次子操作何时结束，因此清理责任不应交给下游函数猜测。

实际代码通常只需要一个固定动作：

func loadProfile(parent context.Context) (Profile, error) {
    // 当前函数拥有派生上下文，所有返回路径都要触发 cancel。
    ctx, cancel := context.WithTimeout(parent, 2*time.Second)
    defer cancel()

    // 下游通过 ctx 感知截止时间或父级取消。
    return fetchProfile(ctx)
}

defer 不是“等超时才执行”，而是在 loadProfile 返回时执行。这样无论请求成功、下游报错，还是中途提前返回，清理动作都只有一个出口。

为什么超时了仍然应该显式调用 cancel

很多人会想：既然 WithTimeout 到点会自动取消，那不调用也能结束。这个说法只对“最终会收到取消信号”这一半成立。官方文档明确建议在操作完成后尽快调用 cancel；当计时器仍在运行时，取消函数可以释放与该派生上下文关联的资源，不必等到截止时间自然到达。

因此，cancel 有两个作用：一是向正在等待 Done() 的 goroutine 广播停止信号，二是让当前操作已经结束时的计时器和父子关系尽早收尾。它不是内存垃圾回收，也不能凭空关闭网络连接；下游必须真正监听 ctx.Done()，具体资源也要由其所有者关闭。

循环和 goroutine 最容易把取消边界写错

循环里直接写 defer cancel()，清理会推迟到外层函数返回。如果循环很长，就会同时保留很多尚未到期的计时器。把每次迭代包进小函数，能让 defer 对准一次任务：

for _, id := range ids {
    // 小函数结束后立即执行本轮 cancel，而不是等整个循环结束。
    err := func() error {
        ctx, cancel := context.WithTimeout(parent, time.Second)
        defer cancel()

        // 本轮任务只把 ctx 交给需要它的调用。
        return syncOne(ctx, id)
    }()
    if err != nil {
        return err
    }
}

并发场景则要先明确所有权：父函数可以创建上下文并在收拢子任务后取消；子 goroutine 不应该拿到一个会被过早取消的局部上下文。goroutine 内部至少要在阻塞点选择 ctx.Done()：

select {
case result := 

用一张清单判断是否真的释放

• 每次创建 WithCancel、WithTimeout 或 WithDeadline 后，是否在同一层立刻安排了 defer cancel()？
• 下游阻塞操作是否传入了这个 ctx，并在 Done() 关闭时退出？
• 循环是否把一次迭代包在小函数里，避免所有 cancel 都堆到外层返回？
• 数据库 rows、HTTP response body、文件和 ticker 是否仍由各自的关闭函数负责？

最后一项很关键：context 只描述取消、截止时间和请求范围值。它能让协作者知道“工作不再需要”，却不替你执行 rows.Close() 或 resp.Body.Close()。把两类清理都写清楚，资源曲线才会和代码意图一致。

常见问题

只调用 cancel，不等待 goroutine 结束可以吗？

不够。cancel 只是发出信号；需要用 WaitGroup、结果通道或其他同步方式确认 goroutine 已经退出。

父 context 结束后还需要调用子 context 的 cancel 吗？

仍建议调用。父级取消保证传播，但子操作由创建者收尾能让代码责任清晰，也能在父级尚未结束时提前释放自己的计时器。

把 context 存进结构体能解决忘记 cancel 吗？

不能。context 通常应作为函数参数传递；把它存进结构体会模糊生命周期，反而更难判断谁负责取消。

官方资料可从 https://pkg.go.dev/context 的包文档和 Go Blog 的 Context 文章继续核对。实际排查时，先找派生上下文的创建点，再沿返回、超时和 goroutine 退出路径确认 cancel 与具体资源关闭是否都存在。