不会直接增加调度开销，但不当使用会引发 goroutine 泄漏和定时器堆积，间接拖慢系统；关键在于是否及时调用 cancel()、是否在非阻塞路径滥用。
context.WithTimeout 会增加调度开销吗？
不会直接增加调度开销，但不当使用会引发 goroutine 泄漏和定时器堆积，间接拖慢系统。关键不在 context.WithTimeout 本身，而在于是否及时调用 cancel()、是否在非阻塞路径上滥用它。
- 每次调用
context.WithTimeout都会启动一个后台time.Timer，若未调用cancel()，该 timer 会一直存活到超时触发，期间占用堆内存和定时器轮询资源 - 在高频短生命周期函数（如 HTTP 中间件、日志埋点）中反复创建带 timeout 的 context，容易积累大量待触发 timer，尤其在高并发下会显著抬高 Go runtime 的定时器管理负载
- 如果只是想标记“当前请求开始时间”，用
context.WithValue存time.Now()更轻量；只有真正需要中断下游操作（如 cancel HTTP 请求、关闭数据库连接）时，才需WithTimeout
如何避免 context.Background() 被误传导致超时失效
常见错误是中间层无意中用 context.Background() 替换了上游传入的带 deadline 的 context，导致整个调用链失去超时控制。典型场景包括：封装 SDK 客户端、复用工具函数、日志或 metric 上报逻辑。
- 所有接受 context 的函数签名必须显式声明
ctx context.Context参数，禁止内部硬编码context.Background() - 在封装第三方 client（如
redis.Client或http.Client）时，确保每个方法都透传ctx，例如：client.Get(ctx, key)，而不是client.Get(context.Background(), key) - 若必须 fallback，默认应使用
ctx而非Background()，比如：if ctx == nil { ctx = parentCtx // 或直接 panic("nil context") }
select + context.Done() 里忘了 defer cancel() 怎么办
漏掉 defer cancel() 是最隐蔽的性能隐患之一：goroutine 不会自动退出，timer 不会释放，context 树无法被 GC，长期运行服务会出现内存缓慢增长和 goroutine 数持续上升。
- 只要调用了
context.WithCancel/WithTimeout/WithDeadline，就必须确保对应cancel()被调用，且优先用defer—— 即使函数提前 return 或 panic - 不要在
select分支里调用cancel()后就结束函数，因为其他分支可能还没执行完；defer cancel()应放在函数开头紧随 context 创建之后 - 检查现有代码可 grep：
grep -r "WithCancel\|WithTimeout\|WithDeadline" . --include="*.go" | grep -v "defer cancel"
，再人工确认是否遗漏
HTTP handler 中 context 超时设置多少才合理
没有统一值，取决于下游依赖的 P99 延迟和业务容忍度。设得太短会导致大量无意义重试和用户体验下降；设得太长会让故障传播更久、连接池耗尽更快。
立即学习“go语言免费学习笔记（深入）”；
- 不要全局设成 30s。对内部 RPC，建议设为下游 P99 + 200ms；对外部 API，至少加 1s 网络抖动余量
- 用
http.Server.ReadTimeout和WriteTimeout控制连接级超时，它们与 handler 内部的 context 超时是正交的——前者防 TCP 慢攻击，后者防业务逻辑卡死 - 若 handler 内需并发调用多个服务，用
context.WithTimeout(parentCtx, 500*time.Millisecond)，而非给每个子调用单独设 timeout，否则总耗时可能突破预期
