Go context deadline 到期后后台 goroutine 为什么还没退出

调用 context.WithTimeout 后，deadline 到期并不会替你“杀掉”后台 goroutine。它只会让派生 context 的 Done() channel 关闭，并让 Err() 返回 context deadline exceeded；goroutine 是否退出，取决于自己的代码有没有选择这个信号、当前阻塞点能不能被取消，以及退出前的清理是否完成。

先把 deadline、Done 和 goroutine 生命周期分开

WithTimeout 建立的是一棵 context 树。计时器到点后，派生 context 会进入取消状态，Done 关闭，Err 给出原因；这些动作并不等于运行时强行终止某个 goroutine。Go 没有安全的“杀线程”接口，因为 goroutine 可能正持有锁、写文件或更新共享状态。

因此，下面这个现象是正常的：主流程已经打印 deadline exceeded，但后台函数仍在打印工作日志。它没有监听取消信号，或者正卡在一个无法响应 context 的操作上。

循环里监听 Done，发送时也要留出口

常见修复不是在 goroutine 外面再加一个定时器，而是让每个可重复工作单元都能结束。尤其要检查两个位置：循环开始前的等待，以及把结果发送到下游 channel 的时刻。下游提前退出时，单纯的 out 也可能让生产者永久等待。

package main

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

func worker(ctx context.Context, out chan

这里的关键不是 time.After，而是两个 select 都把 ctx.Done() 放进了竞争分支。第一个控制工作循环，第二个保护发送动作。WaitGroup 只负责等待，不负责取消；职责分开后，日志中的“deadline 到期”和“worker stopped”也不会被误认为同一时刻。

如果 goroutine 仍不退出，先找不响应取消的阻塞点

即使循环写了 select，只要它在进入下一次检查前卡住，退出仍会延迟。例如直接调用一个没有 context 参数的网络读取、等待永不关闭的 channel，或执行很长的本地计算。此时要把阻塞点列出来，而不是继续缩短 timeout。

支持 context 的函数会在取消后尽早返回，但这仍是“协作式”语义，不保证纳秒级中断。比如数据库驱动、远端服务或操作系统 I/O 还可能有自己的收尾延迟。调用方应该把 context 继续向下传递，而不是在后台 goroutine 中重新使用 context.Background()，否则原来的 deadline 就被切断了。

用等待和错误原因确认它真的结束

排查时不要只看 ctx.Err()。它只能说明 context 已取消，不能证明 goroutine 已返回。生产代码通常需要一个明确的生命周期闭环：创建派生 context，启动工作，遇到 Done 返回，释放资源，最后由调用方等待。

还要区分 context.Canceled 和 context.DeadlineExceeded：前者通常表示主动调用了 cancel，后者表示 deadline 或 timeout 到期。把两者分别记录，才能判断是上游请求撤销、下游超时，还是服务内部的时间预算太短。

常见问题

context deadline 到期后能强制结束 goroutine 吗？

不能。context 只提供取消信号，goroutine 必须在自己的代码和可取消 API 中协作退出。

为什么已经写了 select，goroutine 还是慢几秒？

它可能正卡在 select 之前的不可取消调用，或者正在等待底层 I/O 收尾。把每个阻塞点单独标记并传递 context。

调用 cancel 后还要调用 WaitGroup.Wait 吗？

如果需要确认后台任务已停止、锁已释放或文件已关闭，就要等待。cancel 发出信号，Wait 才确认生命周期结束。

记住一个边界：deadline 到期是 context 的状态变化，goroutine 退出是业务代码完成的结果。把 Done 传到循环、发送和外部调用，再用等待机制收口，后台任务才不会变成“请求结束了但工作还活着”的隐性泄漏。