Go context.WithTimeout 会自动停掉 goroutine 吗：取消信号和阻塞点怎么处理

很多 Go 新手第一次用 context.WithTimeout 时，会以为超时时间一到，相关 goroutine 就会自动停掉。实际不是这样：context 只负责发出取消信号，真正退出还要看你的代码有没有监听 ctx.Done()，以及正在等待的网络、数据库、channel、锁这些阻塞点能不能被取消。

一句话讲清：context 只发信号，不负责停人

context.WithTimeout(parent, 2*time.Second) 会创建一个带截止时间的上下文。到期后，ctx.Done() 对应的通道会关闭，ctx.Err() 通常会返回 context deadline exceeded。这就是它的职责边界。

它不会暂停 goroutine，不会打断任意阻塞调用，也不会把某个函数从半路拽出来。Go 没有提供那种随意终止协程的安全机制，因为函数可能正拿着锁、正在写文件、正在更新共享状态，硬停反而更危险。更可靠的方式是协作式取消：调用方发信号，被调用方在合适位置检查信号，然后自己收尾退出。

为什么很多代码超时后 goroutine 还在

常见问题不在 WithTimeout 本身，而在阻塞点没有接住 ctx。下面这个例子里，外层 select 能等到超时，但子 goroutine 里的 slowCall() 如果一直不返回，goroutine 仍然挂在那里。

func handle() error {
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancel()

	done := make(chan error, 1)
	go func() {
		done 

这段代码看起来很像“超时控制”，但只控制了 handle 的返回时间，没有控制 slowCall 的生命周期。如果 slowCall 卡在一个不支持取消的读取、锁等待或第三方库调用里，外层函数已经返回，子 goroutine 还会继续等。

正确姿势：把 ctx 传到真正等待的地方

能传 ctx 的地方就不要绕开。HTTP 请求用 http.NewRequestWithContext，数据库查询用 QueryContext，写操作也要选对应的上下文版本方法，RPC 客户端通常也有带上下文的调用形式。这样超时信号能传到真正做 I/O 的地方，而不是停在外层。

func fetch(ctx context.Context, url string) error {
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return err
	}

	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		return err
	}
	defer resp.Body.Close()

	return nil
}

func handle() error {
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancel()

	return fetch(ctx, "https://example.com/api")
}

这时 fetch 里的 HTTP 请求知道外层上下文已经超时，底层等待才有机会被打断。注意这里还是“有机会”，不是所有第三方库都处理得一样好，所以关键路径上线前要做超时验证。

循环和 channel 等待要自己监听 Done

很多后台 worker 泄漏，不是因为 HTTP 或 SQL，而是因为循环里只等业务 channel，没等 ctx.Done()。一旦上游不再发数据，worker 就挂在接收操作上，外层 cancel 也叫不醒它。

func worker(ctx context.Context, jobs 

这段代码的关键是把业务等待和取消等待放在同一个 select 里。只要上下文到期或上游主动取消，worker 就能从等待中醒过来，然后按自己的规则释放资源、结束循环。

cancel 也别漏：它不是装饰代码

cancel() 需要调用，哪怕你觉得超时时间很短。它会释放 context 关联的计时器和父子关系资源。最常见写法是创建后立刻 defer cancel()，除非这个上下文被明确交给更外层统一管理。

不过也别把 defer cancel() 当成万能药。它只负责告诉下游“该停了”，不负责保证下游一定停。排查泄漏时，看到 defer cancel() 只能说明资源释放动作写了，后面还要继续追阻塞点。

怎么判断有没有真的退出

最小验证不要只看接口是否按时返回，还要看 goroutine 数量、日志和阻塞栈。测试环境可以在请求前后记录 runtime.NumGoroutine()，压一段时间后观察是否持续上涨；更可靠的方式是抓 goroutine profile，看大量协程是不是卡在同一个读、写、锁或 channel 等待位置。

常见问题

WithTimeout 到期后一定会返回 context deadline exceeded 吗？

如果是超时触发，通常会看到 context deadline exceeded。如果是外部主动调用 cancel()，常见结果是 context canceled。具体返回值要看你检查的是 ctx.Err() 还是下游库包装后的错误。

只要 defer cancel 就不会泄漏吗？

不够。defer cancel() 可以释放 context 自身资源，也能通知下游取消；但如果下游没有监听 Done，或者阻塞调用不支持取消，goroutine 仍可能继续挂住。

context 可以在结构体里长期保存吗？

一般不建议。context 更适合随请求、任务或调用链传递。长期放在结构体里容易混淆生命周期，也容易把一个已经取消的上下文继续复用。

后台任务要不要用 context.Background？

可以作为根上下文，但最好在具体任务上再派生带取消或超时的子上下文。后台任务也需要退出路径，比如服务关闭、任务超时、依赖不可用时都应该能收尾。

小结

context.WithTimeout 解决的是“什么时候通知取消”，不是“怎样强行停止 goroutine”。写 Go 超时代码时，要把 ctx 传到真正等待的调用里，在循环和 channel 等待处监听 Done，并用 profile 或压测确认协程能退出。理解这条边界，很多看似玄乎的 goroutine 泄漏问题就能少走弯路。