Go 上下文WithCancel 派生后 goroutine 仍不退出怎么办

如果调用 context.WithCancel 后发现派生的 goroutine 仍然不退出，先记住一句话：取消 Context 只发送取消信号，不会替你强制销毁 goroutine。真正的退出取决于 goroutine 是否监听 ctx.Done()，以及它正在等待的底层操作是否也能被取消。

这类问题通常不是 WithCancel 失效，而是“信号已经发出，但工作函数没有消费信号”或“工作函数卡在不可取消的阻塞点”。下面按迁移变更单的方式，把旧写法和可收敛写法放在一起。

排查顺序：先看 ctx.Err() 是否已经非空，再看 goroutine 是否有 分支，最后检查 HTTP、数据库或自定义 channel 是否提供取消入口。

为什么 WithCancel 不会直接杀掉 goroutine

WithCancel(parent) 返回一个派生 Context 和一个 CancelFunc。调用 cancel 会关闭这个派生 Context 的 Done 通道；父 Context 的取消也会向下传播，但子 Context 的取消不会反向取消父 Context。Go 官方文档还特别说明，及时调用 cancel 可以释放 Context 关联的资源。

因此，下面这种代码只能保证“发出了取消信号”，不能保证 worker 已经退出：

ctx, cancel := context.WithCancel(context.Background())
go func() {
	// 这里只做循环，不读取 ctx，取消信号没有消费者。
	for job := range jobs {
		process(job)
	}
}()

cancel() // 只取消 Context，不能强行结束上面的 goroutine

如果 worker 还需要执行收尾动作，应该把“取消请求”和“已经退出”分成两个状态，用 WaitGroup 或完成通道等待后者。

先确认 goroutine 是否真的收到了取消信号

不要先给 cancel() 增加重试。先在 worker 入口和退出分支观察 ctx.Err()：返回 nil 表示尚未取消，返回 context.Canceled 或 context.DeadlineExceeded 才表示取消链已经生效。

还要确认传入 worker 的是派生后的 ctx，而不是外层的 context.Background()。这种变量替换是常见的迁移遗漏：

workerCtx, cancel := context.WithCancel(parent)
defer cancel()

// 传入 workerCtx，不能误传 parent 或 Background。
go runWorker(workerCtx, jobs)

func runWorker(ctx context.Context, jobs 

如果 ctx.Err() 已经非空，但 goroutine 数量仍不下降，故障点就不在取消传播，而在 worker 没有走到这个 select，或者 process 内部长期阻塞。

把 worker 改成可退出的写法

更稳妥的改法是让任务函数也接收 Context。循环层只负责选择“新任务还是取消”，任务层再把 Context 传给具体依赖；这样不会出现外层可退出、内层却继续等待的半截修复。

func runWorker(ctx context.Context, jobs 

退出策略要统一：关闭 jobs 表示不再有新任务，调用 cancel 表示停止当前上下文中的工作，最后等待 worker 返回。不要用一个永远阻塞的无缓冲发送或接收，把最后的退出路径重新堵住。

底层调用阻塞时还要补上取消路径

如果 worker 卡在 process，外层 select 再正确也没有用。常见阻塞点可以按下面的方式迁移：

这不是给每个循环都加一个 cancel() 就能解决的问题。应该沿着调用链把同一个 Context 传到真正可能等待的 API，并在资源拥有者的作用域结束时调用 cancel。

发布前回归清单

• 取消后，worker 的循环有明确的 Done 分支。
• 任务处理函数没有丢弃 Context，也没有重新创建 Background。
• HTTP、数据库和自定义 channel 都有对应的中断或关闭策略。
• 测试同时覆盖“收到任务”“任务处理中取消”“jobs 关闭”“父 Context 取消”四种情况。

相关问题

调用 cancel 后 Done 会同步关闭吗？ 不要把 goroutine 已经退出和 Done 已经关闭混为一谈；调用方应通过 worker 的完成信号确认退出。

只在 goroutine 外层 defer cancel 可以吗？ 可以作为资源释放习惯，但它不能代替 worker 内部的取消分支，也不能解除不可取消的阻塞调用。

为什么改成 WithTimeout 仍然不退出？ 超时同样只是让 Context 进入取消状态；底层工作必须主动读取 Done 或使用支持 Context 的 API。