context.WithTimeout 必须显式调用 cancel()，否则 timer 和 goroutine 泄漏；HTTP/gRPC/DB 调用须透传 context 而非依赖客户端超时；取消监听必须用 select ctx.Done()，不可轮询 ctx.Err()。
context.WithTimeout 必须显式调用 cancel()，哪怕超时已触发
很多人以为 context.WithTimeout 超时后自动清理就万事大吉，其实不然：内部 time.Timer 和关联 goroutine 仍存活，不调用 cancel() 就会泄漏。
- 正确写法永远是：
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)，并在作用域末尾defer cancel() - 即使请求早已超时，
cancel()仍能提前释放 timer 和 goroutine，避免累积泄漏 - 不要只接收
ctx忽略cancel，也不要 defer 里调两次（幂等但无意义，还可能掩盖逻辑错误）
HTTP 请求必须把 context 传给 client.Do()，不是只设 req.Context()
http.Client.Timeout 只控制从 dial 到读完 body 的总时间，无法覆盖 DNS 解析、TLS 握手、连接池阻塞等前置环节；只有 context 能穿透全链路。
- 错误写法：
req = req.WithContext(ctx)后调用client.Do(req)→ctx不生效 - 正确写法：
client.Do(req.WithContext(ctx))或先赋值再传参，确保Do()内部真正监听该ctx.Done() - gRPC、database/sql 等库同理：必须显式传入
ctx，不能依赖客户端默认超时
微服务调用链中要透传 context，别在中间层重设超时
上游服务 A 调用 B，B 再调用 C，整条链路应共享同一超时约束。若 B 自行新建 context.WithTimeout(ctx, 2*time.Second)，会导致取消信号中断、超时嵌套混乱。
- 透传原则：所有下游调用都用原始
ctx或其派生（如context.WithValue(ctx, key, val)），保持树形传播 - 仅当有明确子任务 SLA 时才分层设限，例如外层总超时 30s，内层 DB 查询单独设 25s，但必须用
context.WithTimeout(ctx, ...)派生，而非新建 root context - 若中间服务需加 traceID 或 auth token，用
context.WithValue()，key 必须是自定义类型，禁用 string（易冲突）
监听取消必须用 select，不能轮询 ctx.Err()
ctx.Err() 在取消前恒为 nil，轮询它等于无效判断；ctx.Done() 是个永不为 nil 的 channel，关闭后立即可读——唯一可靠响应方式是 select。
- 错误写法：
for ctx.Err() == nil { ... }或循环开头if ctx.Err() != nil→ 无法及时退出阻塞操作 - 正确模式：在任何等待点（channel recv、time.Sleep、数据库 rows.Next()）都并列监听
ctx.Done() - 对不支持 context 的第三方库，自己封装 select + timer 或 channel 中断逻辑，确保资源可回收
真正的难点不在语法，而在每一层是否真正“尊重” context：是否传下去、是否监听、是否清理。漏掉任意一环，取消信号就断在那儿，协程和连接照常泄露。
