context.WithCancel仅用于主动终止关联协程，如长轮询、流响应、后台任务超时控制；禁用于短平快纯计算（如JSON序列化）、每个HTTP handler盲目封装，且须确保cancel()被调用，否则导致goroutine泄漏。
context.WithCancel 什么时候该用，什么时候不该用
用 context.WithCancel 的核心目的只有一个：主动终止一组关联协程。不是为了传参数，也不是为了“看起来更规范”。它只在你明确知道「某个操作可能中途被外部打断」时才值得引入。
常见误用场景：给每个 HTTP handler 都套一层 context.WithCancel，结果忘了调用 cancel()，导致 goroutine 泄漏；或者在纯内存计算函数里硬塞 context，徒增 nil 检查和取消监听开销。
- 该用：长轮询、流式响应、后台任务超时控制（配合
time.AfterFunc） - 不该用：短平快的数据库查询封装（除非上层已传入可取消 context）、配置解析、JSON 序列化等无阻塞纯计算逻辑
- 关键提醒：每次调用
context.WithCancel都会生成一个新 context 和一个必须手动调用的cancel函数——漏调 = 协程永远卡在select上
为什么 http.Request.Context() 返回的 context 不能直接传给子协程做 cancel 控制
因为 http.Request.Context() 是 request 生命周期绑定的，它的取消时机由 HTTP 连接关闭或客户端断开决定，**不是你业务逻辑能掌控的**。拿它来控制后台异步任务（比如发消息、写日志），很容易出现“请求结束了但任务还在跑”或“任务刚启动就被 cancel”的错位。
正确做法是基于它派生出自己的 cancelable context，并在合适时机主动 cancel。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
go doSomething(req.Context())—— 一旦用户关掉页面，doSomething可能被意外中断 - 正确写法：
ctx, cancel := context.WithTimeout(req.Context(), 5*time.Second); go doSomething(ctx); defer cancel() - 注意：如果
doSomething是 fire-and-forget 类型（如推送通知），建议用context.Background()+ 独立超时，避免受 request 生命周期干扰
context.WithValue 安全传参的三个硬约束
context.WithValue 不是通用传参工具，它是为跨多层调用传递「请求级元数据」设计的，比如 trace ID、用户身份、租户标识。滥用会导致 context 膨胀、类型难维护、取消语义混乱。
- 键必须是 unexported 类型（推荐用私有 struct{} 或 int），否则不同包可能冲突：
type ctxKey string; const userKey ctxKey = "user" - 值必须是只读的（
string、int、不可变 struct），禁止传指针或 map/slice——协程间共享可变状态会引发竞态 - 只在真正需要穿透中间件/中间层时才用；同一函数内能用参数传就别塞 context，比如
func handle(ctx context.Context, userID string)比ctx.Value(userKey).(string)更清晰、更易测
Deadline 和 Done channel 在 select 中怎么写才不漏 cancel
很多人以为只要写了 case 就万事大吉，其实漏掉了最危险的一种情况：select 前已有阻塞操作（比如 channel send/receive、锁等待），而 context 已经 cancel，但代码还没走到 select。
本质问题是：context 取消本身不会中断正在执行的系统调用或 channel 操作，它只是让 Done() channel 关闭，你需要确保所有可能阻塞的地方都受控于这个 channel。
- 对 channel 操作，必须用带 timeout 的 select：
select { case ch - 对 net.Conn 操作，要用
SetReadDeadline/SetWriteDeadline配合 context deadline，不能只依赖ctx.Done() - 对 sync.Mutex，无法直接响应 cancel，需改用
sync.RWMutex+context.Context控制读写路径，或用semaphore.Weighted替代
context 的 cancel 信号是被动的，它不强制中断，只提供退出协商机制。真正难的是把这种协商织进每一段可能阻塞的代码里，而不是靠一次 WithCancel 就高枕无忧。
