Go context 怎样避免在长任务中忘记调用取消函数

在 Go 的长任务里，最稳妥的习惯是：context.WithCancel 返回后马上写 defer cancel()，再把派生出的 ctx 传给所有需要响应停止信号的下游函数。这样，当前函数无论是正常返回、提前报错还是主动中止，都能执行同一条清理路径。

关键点不在于“调用过 cancel 就一定能停掉所有 goroutine”，而在于建立两条边界：父函数负责释放派生 context，下游任务负责监听 ctx.Done() 并自行退出。官方文档说明，CancelFunc 会取消子 context 及其子孙、移除父级对子节点的引用；遗漏调用会让这棵子树一直保留到父 context 被取消。

• 创建者负责：保存并调用 cancel，通常紧跟在 WithCancel 后面。
• 执行者负责：在循环、等待和 I/O 边界检查 ctx.Done()。
• 调用者负责：根据 ctx.Err() 区分自然完成、主动取消和上游取消。

规模背景：长任务为什么容易遗忘 cancel

短函数里忘记清理通常很快暴露，但批量导入、后台同步或多 goroutine 协作往往会把派生 context 放在函数中段：先创建一个任务上下文，再启动多个 worker，最后等待结果。随着分支增加，开发者容易只关注“任务能不能完成”，却忘记“任务完成后谁负责释放派生 context”。

可以把责任拆成四个静态角色：入口函数创建任务边界，派生 context 承载取消信号，worker 监听信号并停止生产，收尾逻辑释放上下文资源。图 1 是这个关系的结构说明图，不是运行截图，也不代表某个真实系统的执行结果。

原架构瓶颈：只调用 Done，不建立 cleanup 责任

常见的半成品写法是把 ctx 传入 worker，却没有在创建位置保存 cancel；或者只在“提前失败”的分支调用 cancel，正常返回路径没有统一清理。前一种写法让派生 context 的生命周期依赖父 context，后一种写法让清理逻辑散落在分支里。

func runBatch(parent context.Context, jobs 

这里的 defer cancel() 是兜底，而不是替代 worker 的退出逻辑。cancel 只负责关闭取消信号并释放 context 关联资源；WaitGroup 才负责等待本函数启动的 goroutine 完成。两者解决的是不同问题。

新架构：把取消信号接到每个阻塞边界

如果 worker 只在循环顶部检查一次 ctx.Err()，但随后在不可中断的发送、接收或外部调用中长时间阻塞，cancel 仍然不能让它立刻返回。更可靠的做法是把 ctx.Done() 放进每一个可能等待的 select，并让下游函数继续接收同一个 ctx。

当任务自然耗尽时，关闭 jobs 让 worker 正常返回；当某个 worker 失败时调用 cancel，其它 worker 在自己的监听点退出；当上游取消时，父 context 的信号沿树传播。三条路径最终都经过 defer cancel()，因此不需要为每个分支复制清理代码。

关键取舍：cancel 不等于强制杀死 goroutine

Go 的 CancelFunc 可以被多个 goroutine 并发调用，重复调用没有额外效果，但它不会等待工作停止。因此，拥有 goroutine 的函数仍应决定如何等待、回收结果和关闭其它资源。把 cancel 当成“终止线程”的做法，会掩盖下游没有监听 Done 的问题。

返回错误时也要看语义：context.Canceled 表示取消信号已经传播，context.DeadlineExceeded 则表示期限到达。若任务本身成功耗尽，通常应返回业务结果而不是把正常关闭误报成取消。这个判断可以放在等待完成之后，避免把清理动作和业务结果混为一谈。

上线后的检查：让责任边界可维护

团队可以把以下约定写进代码评审清单：凡是调用 WithCancel、WithTimeout 或 WithDeadline 的函数，下一行就保存对应的取消函数；凡是启动 goroutine 的函数，说明它在哪些 Done 监听点退出，以及谁等待它结束。官方文档还提到，go vet 会检查 CancelFunc 是否覆盖所有控制流路径，可把它作为静态提醒。

# 用静态分析提醒遗漏的取消函数路径；它不是运行时回收器。
go vet ./...

最后记住一个范围：defer cancel() 能保证当前函数离开时释放派生 context，但不能替你修复不响应取消的下游代码。真正可维护的长任务，必须同时具备“创建处统一清理”和“执行处主动退出”两层约束。

常见问题

为什么 WithCancel 后要立刻 defer cancel？

因为创建者最清楚这个派生 context 的生命周期，紧跟着注册 defer 可以覆盖正常返回、错误返回和后续新增分支，减少遗漏。

调用 cancel 后 goroutine 还在运行，是否说明失败？

不一定。CancelFunc 只发送取消信号，不等待 goroutine 结束。worker 必须监听 ctx.Done()，外层再用 WaitGroup 或其它明确的收尾机制等待它完成。

任务自然结束时还需要调用 cancel 吗？

需要。即使任务已经完成，调用 cancel 仍是释放派生 context 关联资源的统一路径；重复调用是安全的。