Worker池中传context必须用WithCancel派生子上下文，避免共享ctx导致取消信号污染；WithTimeout/WithDeadline应按任务单独设置；元数据优先用WithValue传递；关闭时需通知所有活跃worker响应Done()退出。
Worker池里传context必须用WithCancel重新派生
直接把同一个 ctx 传给所有worker会导致取消信号无法按需隔离——比如一个worker出错触发cancel，整个池子全停。正确做法是在每次分发任务前，用 context.WithCancel() 基于父上下文创建新子上下文。
常见错误现象：多个worker共享一个带超时的 ctx，某个worker提前返回后调用 cancel()，其余worker立刻收到 ctx.Done() 并中断，哪怕它们还没开始执行。
- 每次从任务队列取一个
Job，就调用context.WithCancel(parentCtx)创建专属jobCtx - 把
jobCtx和任务数据一起传给worker goroutine - worker内部只监听自己的
jobCtx.Done()，不碰父上下文的cancel函数 - worker结束时自行调用自己持有的
cancel（可选，防止泄漏）
WithTimeout和WithDeadline在Worker池中要慎用
context.WithTimeout() 和 context.WithDeadline() 创建的上下文自带定时器，一旦超时会自动调用内部 cancel()。在动态池中，如果所有worker共用同一个超时上下文，或复用未重置的定时器，会出现“时间漂移”或意外提前取消。
使用场景：适合对单个任务设硬性时限（如HTTP请求最多等3秒），不适合控制整池生命周期。
立即学习“go语言免费学习笔记（深入）”；
- 不要在池初始化时一次性创建
ctx, cancel := context.WithTimeout(...)然后复用 - 每个任务启动时单独调用
context.WithTimeout(parentCtx, taskTimeout) - 注意
taskTimeout应基于任务类型设定，而非统一固定值（如DB查询2s、缓存100ms） - 避免嵌套多层
WithTimeout，否则Deadline可能被反复覆盖，行为不可预测
WithValue传递任务元数据比全局map更安全
Worker池常需透传请求ID、用户身份、traceID等元数据。有人倾向用外部map存映射关系，但并发读写易出竞态；也有人直接塞进任务结构体，导致每个Job都冗余字段。更轻量且线程安全的做法是用 context.WithValue() 包一层。
性能影响：WithValue 是链表式追加，每层新增一个节点，频繁调用（如每毫秒千次）会有微小开销，但对常规业务无感。
- 键类型必须是导出的、可比较的类型（推荐自定义类型，如
type ctxKey string），避免用字符串字面量作key - 不要用
WithValue传大对象（如结构体指针），只传轻量标识符或token - 若需传多个字段，打包成一个结构体再传，而不是链式调用多次
WithValue - worker内通过
ctx.Value(myKey)获取，记得做类型断言和ok判断
池关闭时如何优雅终止所有活跃worker
动态Worker池支持运行时扩容缩容，但关闭时必须确保所有正在执行的worker能响应取消并退出，不能靠 time.Sleep() 硬等。
容易踩的坑：仅关闭任务队列通道，worker因阻塞在 而退出，但已取出任务的worker仍继续跑，失去控制。
- 维护一个活跃worker计数器（
sync.WaitGroup），每启动一个worker就Add(1)，结束时Done() - 关闭信号应同时广播给所有worker的
jobCtx（通过父cancel()触发级联） - worker函数内部需监听
jobCtx.Done()并及时清理资源（如关闭DB连接、释放内存） - 主goroutine调用
wg.Wait()等待全部完成，再真正释放池资源
关键点在于：worker的生命周期由它自己的 jobCtx 控制，而池的关闭动作只是批量触发这些子上下文的取消——这正是context设计的本意，不是靠“杀协程”，而是靠“通知退出”。
