worker启动时必须接收context.context参数，否则上层无法取消；传context.background()或内部新建独立ctx均导致ctx.done()永不触发、select无法响应取消。
worker 启动时没传 context.Context 就等于没留退路
Go 里 worker 要能被取消，第一关就是启动时必须接收 ctx。不传、传 context.Background() 硬编码、或者只在内部新建一个不继承的 context，都会让上层调用方彻底失去控制权。
常见错误现象：ctx.Done() 永远不触发，select 里 case 像摆设；调用 <code>cancel() 后 worker 还在疯狂处理任务、goroutine 泄漏。
- worker 函数签名必须是
func(ctx context.Context, jobChan 这类形式，不能省略 <code>ctx - 如果 worker 内部还要起子 goroutine（比如发 HTTP 请求），每个子 goroutine 都得把
ctx传进去，不能只靠闭包捕获外层变量 - 避免在 worker 中调用
context.WithCancel(context.Background())—— 这会断开与上游的取消链路
worker 循环里漏了 ctx.Err() != nil 检查就会卡死
很多同学以为只要写了 select { case 就万事大吉，但实际中，worker 往往有同步阻塞操作：读 channel、调用 <code>time.Sleep()、等锁、或调用没带 context 的第三方库函数（比如 http.Get()）。这些地方不会自动响应 cancel，必须手动加退出判断。
使用场景：批量处理日志、轮询数据库、长连接心跳。
立即学习“go语言免费学习笔记（深入）”；
- 每次从
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
事情说清了就结束
