Go context.WithTimeout 子协程为什么没有随超时退出怎样构造最小复现

调用 context.WithTimeout 后，父函数已经返回，子协程却还在打印日志，通常不是超时没有生效，而是把“取消通知”误解成了“强制杀死 goroutine”。超时发生后，Context 会发出取消信号；子协程只有在监听 ctx.Done()，并且当前阻塞操作允许被打断时，才会主动返回。

官方地址：https://pkg.go.dev/context

排查顺序是：先确认超时 Context 的 Err() 已变成 context deadline exceeded，再检查子协程有没有读取 ctx.Done()，最后确认它依赖的 I/O、锁或第三方调用是否也支持取消。

背景：WithTimeout 到底改变了什么

WithTimeout(parent, d) 返回一个从父 Context 派生出来的子 Context 和一个 cancel 函数。到达截止时间，或者代码提前调用 cancel() 时，子 Context 会被标记为已取消，Done() 对应的通知通道会关闭，Err() 则可以告诉调用方是主动取消还是超过截止时间。

这个机制只负责把取消状态沿 Context 树传播下去。它不会扫描所有 goroutine，也不会在后台替业务代码执行清理。可以把它看成一封“请停止工作”的通知：收件人是否及时读信、是否能从当前动作中退出来，仍由收件人的实现决定。

package main

import (
	"context"
	"fmt"
	"time"
)

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 40*time.Millisecond)
	defer cancel() // 无论提前结束还是超时，都释放派生 Context 关联的资源

	

这里的 ctx.Err() 能说明 Context 已经取消，但不能说明任何一个由它启动的 goroutine 已经退出。要判断 goroutine 生命周期，还需要一个明确的完成信号，例如 WaitGroup、结果通道或任务自身的关闭回调。

旧写法问题：为什么超时后子协程还在工作

最小复现不需要网络服务或复杂框架，只要让子协程进入一个永不检查 Context 的循环即可。父函数会在 40 毫秒后看到超时，但子协程仍然继续执行，这正好把两个生命周期分开了。

package main

import (
	"context"
	"fmt"
	"time"
)

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 40*time.Millisecond)
	defer cancel() // 负责结束定时器和派生关系，不负责强制停止 goroutine

	go func() {
		for i := 0; i 

运行时可能先打印 parent: context deadline exceeded，随后仍看到 worker tick。这不是竞态导致的偶然错误，而是示例中的 worker 根本没有退出分支。即使删掉最后的等待，进程很快结束，也不能据此断言 goroutine 已被 Context 回收。

新规则：取消是协作式信号，不是强制终止

Go 的 Context 设计要求调用链主动传播取消。父 Context 被取消时，派生的子 Context 也会被取消，但业务函数必须把 Context 传到真正可能耗时的地方，并在循环、重试、队列等待和 I/O 前后处理它。

所以，给函数增加一个 timeout 参数并不能自动修复 goroutine 泄漏。超时参数只是产生取消信号的条件，退出路径仍需要由代码显式表达。

代码对比：用 select 让子协程真正退出

最小修复是让 worker 在每轮工作前选择“任务完成”还是“Context 已取消”。示例使用 WaitGroup 等待 worker 收尾，避免把“父函数返回”误当成“子协程完成”。

package main

import (
	"context"
	"fmt"
	"sync"
	"time"
)

func worker(ctx context.Context, wg *sync.WaitGroup) {
	defer wg.Done() // 无论正常完成还是收到取消，都通知父流程收尾

	for i := 0; i 

这个版本的关键不是 time.After，而是每次循环都保留一个可选择的取消分支。真实项目中可以把可取消的数据库、HTTP 或文件操作放在 case 对应的工作函数里；如果底层 API 支持传入 Context，应把同一个 ctx 继续传进去。

兼容注意：有了 Done 也不代表所有阻塞都能立即停

如果 goroutine 正卡在一个不接受 Context 的系统调用、第三方 SDK 或长时间持有的锁上，外层即使收到了取消通知，也只能等这次调用返回后再执行下一轮 select。这时要从阻塞点本身处理取消，而不是在外层重复增加 timeout。

例如 HTTP 请求应使用 http.NewRequestWithContext，数据库调用应优先使用带 Context 的方法；自定义重试循环则应在每次重试前和等待期间检查 ctx.Done()。对于无法中断的老 API，可以把单次调用拆小、设置它自己的超时，或通过拥有该资源的库提供的关闭方法释放阻塞。

另一个常见问题是为了“隔离”而在子函数里重新使用 context.Background()。这样会切断父级取消链，外层超时自然无法到达它。除非明确要启动独立于请求生命周期的后台任务，否则不要丢弃传入的 ctx。

采用建议：用四个问题确认退出路径

遇到“超时后子协程没有退出”时，可以按下面的顺序快速定位：

1. 父 Context 的 Err() 是否已经返回 context deadline exceeded 或 context canceled？如果没有，先查 deadline 是否真的创建成功。
2. 子协程是否拿到了同一个派生 Context？检查是否在中途重新创建了 Background()。
3. 循环、重试和等待是否有 select { case 退出分支？没有的话，取消只会停留在通知层。
4. 当前阻塞调用是否也支持 Context？如果不支持，就补齐调用级超时、缩短阻塞粒度或使用可关闭的资源。

最后，给每个 goroutine 建立一个可观察的完成信号。WaitGroup 适合只关心是否结束，结果通道适合传回错误，关闭通知适合让上层继续推进。这样测试时验证的是“取消后 worker 在限定时间内完成”，而不是只验证父函数收到了超时。

相关问题

调用 cancel() 能不能直接杀掉子协程？

不能。cancel() 会让派生 Context 进入取消状态并通知监听者，子协程是否退出取决于它有没有响应通知以及当前操作是否可中断。

为什么已经写了 select，退出仍然很慢？

通常是 select 之前的调用阻塞时间太长，或者调用本身不接受 Context。把取消判断放在阻塞点前后，并选用带 Context 的 API，才能缩短退出延迟。

defer cancel() 和等待子协程有什么关系？

defer cancel() 负责释放派生 Context 及其定时器；它不替代 WaitGroup 或结果通道。需要确认子协程收尾时，仍然要等待它的完成信号。