不能直接传 context.Context 给 goroutine 池任务，因池只接受无参函数且闭包易致 context 生命周期失控；应每次提交前派生子 context（如 WithTimeout），并在任务内显式调用 cancel。
为什么不能直接把 context.Context 传给 goroutine 池里的任务函数
因为大多数 goroutine 池（比如 ants、goflow 或自研池）只接受无参函数或固定签名的 func()，而 context.Context 是运行时才确定的，没法在池启动时“预埋”。强行塞进闭包容易导致 context 生命周期失控——比如父 goroutine 已 cancel，但池中任务还在用已失效的 ctx 做超时控制或取消传播。
用 context.WithCancel 或 context.WithTimeout 包裹任务函数
真正可控的做法是：每次提交任务前，基于当前有效 context 派生出子 context，并把子 context 和任务逻辑一起封装成一个新函数。池执行这个函数时，它自己持有独立生命周期的 context 实例。
- 不要把原始
ctx存到全局变量或池配置里——那会共享取消状态，污染其他任务 - 推荐用
context.WithTimeout(ctx, timeout)而非context.WithDeadline，避免系统时钟跳变引发意外提前 cancel - 如果任务本身要调用带 context 的下游 API（如
http.NewRequestWithContext），直接传入派生出的childCtx
// 示例：向 ants 池提交带 context 的任务
pool.Submit(func() {
childCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()
result, err := doWork(childCtx) // doWork 内部用 childCtx 控制超时
// 处理 result / err
})
自定义任务结构体 + 接口方式更清晰
当任务需要携带多个参数（不止 context），硬塞闭包易读性差，也难统一 cancel 行为。这时定义一个带 Run(ctx context.Context) 方法的接口更稳妥。
- 实现该接口的结构体可内嵌
context.Context字段，或只在Run时接收 - 池提交时显式传入 context，不依赖闭包捕获，语义明确
- 注意：别在结构体里长期保存 long-lived context（如
context.Background()以外的），否则可能阻塞 GC 或延长 cancel 延迟
type Task interface {
Run(ctx context.Context) error
}
// 提交时：
pool.Submit(func() {
err := myTask.Run(ctx) // myTask 是 Task 接口实现
})
小心 context.WithValue 在池中丢失 key
如果你依赖 context.WithValue 传递请求 ID、traceID 等数据，必须确保每次提交任务都重新构造带 value 的子 context。goroutine 池不会自动继承或透传 value，也不会帮你做 deep copy。
- 错误写法：
pool.Submit(func() { use(ctx) })—— 这里ctx是外层变量，value 可能已被上一个任务修改 - 正确写法：每次
Submit前调用ctx = context.WithValue(parentCtx, key, val)，再传入派生 ctx - 更安全的方式是把 traceID 等关键字段抽成结构体成员，而非依赖 context value
实际项目里最容易被忽略的是：**派生 context 后忘记调用 cancel()**。哪怕只是 WithTimeout，不调 cancel 也会让 timer 一直活着，直到超时触发——这在高频短任务场景下会累积大量 goroutine 和定时器。
