Go语言实现带取消的Worker模式与Context应用

在Go语言中，实现可取消的Worker模式必须严格遵循Context传递规范：Worker启动时务必接收外部传入的context.Context参数，否则上层调用方将完全丧失取消控制权；若错误地使用context.Background()硬编码或在内部新建独立Context，会导致ctx.Done()永不触发，使select语句无法响应取消信号，最终让Worker变成“幽灵协程”——既无法优雅退出，也无法被监控和管理。

worker 启动时没传 context.Context 就等于没留退路

Go 里 worker 要能被取消，第一关就是启动时必须接收 ctx。不传、传 context.Background() 硬编码、或者只在内部新建一个不继承的 context，都会让上层调用方彻底失去控制权。

常见错误现象：ctx.Done() 永远不触发，select 里 case 像摆设；调用 cancel() 后 worker 还在疯狂处理任务、goroutine 泄漏。

• worker 函数签名必须是 func(ctx context.Context, jobChan 这类形式，不能省略 ctx
• 如果 worker 内部还要起子 goroutine（比如发 HTTP 请求），每个子 goroutine 都得把 ctx 传进去，不能只靠闭包捕获外层变量
• 避免在 worker 中调用 context.WithCancel(context.Background()) —— 这会断开与上游的取消链路

worker 循环里漏了 ctx.Err() != nil 检查就会卡死

很多同学以为只要写了 select { case 就万事大吉，但实际中，worker 往往有同步阻塞操作：读 channel、调用 time.Sleep()、等锁、或调用没带 context 的第三方库函数（比如 http.Get()）。这些地方不会自动响应 cancel，必须手动加退出判断。

使用场景：批量处理日志、轮询数据库、长连接心跳。

• 每次从 jobChan 取任务前，先检查 if ctx.Err() != nil { return }
• 用 time.AfterFunc() 替代裸 time.Sleep()，或改用 time.Sleep() 前加 select 判断 ctx.Done()
• HTTP 请求必须用 http.NewRequestWithContext(ctx, ...)，不能用 http.Get() 或 http.Post()
• 数据库查询要用支持 context 的方法，比如 db.QueryContext(ctx, ...)，而不是 db.Query(...)

context.WithTimeout 和 context.WithCancel 别混着用

超时控制和手动取消是两种不同意图，混用会导致行为不可预测。比如用 WithTimeout 启动 worker，又在外面另起一个 goroutine 调用 cancel()，结果 timeout 时间还没到就提前退出——这没问题；但如果反过来，在 WithCancel 的 context 上又套一层 WithTimeout，容易让 cancel 信号被覆盖或延迟传递。

性能影响：嵌套过深的 context（比如 5 层以上 WithValue）会有微小开销，但一般不影响 worker 场景；真正伤性能的是在 hot path 里反复调用 ctx.Value()。

• 如果业务需要“最多运行 30 秒”，直接用 ctx, cancel := context.WithTimeout(parentCtx, 30*time.Second)
• 如果业务需要“随时可中断”，用 ctx, cancel := context.WithCancel(parentCtx)，并确保 cancel() 在恰当位置被调用（比如收到 SIGINT、API 返回 4xx、或 manager 主动下线 worker）
• 不要对已 cancel 的 ctx 再调用 WithDeadline —— 新 context 会立刻 Done，且可能掩盖原始 cancel 原因

worker 退出时没清理资源，ctx.Done() 就只是个通知

ctx.Done() 只是告诉你“该停了”，它不负责关闭文件、释放锁、断开连接、或重置状态。很多 bug 表现为：worker 看似退出了，但文件句柄没关、DB 连接没归还、channel 还在写导致 panic。

容易被忽略的地方：worker 里用了 sync.WaitGroup 等待子任务，但子任务没响应 cancel 就一直卡着；或者 defer 里关资源的逻辑写在了 select 外面，根本没执行到。

• 所有 defer 清理逻辑，必须放在 worker 函数最开头，而不是在某个 for 循环里
• 如果用了 sync.WaitGroup，每个子 goroutine 启动前要加 wg.Add(1)，退出前必须 wg.Done()，且要在 ctx.Err() != nil 分支里也调用
• 向下游 channel 发送数据前，先用 select 判断是否还能发：select { case outChan ，避免 panic: send on closed channel

事情说清了就结束

今天关于《Go语言实现带取消的Worker模式与Context应用》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！