context.WithTimeout 本身不直接拖慢系统，但漏调 cancel() 会泄漏 timer、goroutine 和内存，导致定时器堆膨胀、GC 压力增大、P99 延迟上升。
context.WithTimeout 会拖慢系统吗？
不会直接增加调度开销，但不调用 cancel() 就会间接拖垮服务。每次调用 context.WithTimeout 都会启动一个 time.Timer，它不是“免费的”——只要没被显式取消，这个 timer 就会一直待在 Go runtime 的定时器堆里，占用内存、参与轮询调度。
常见错误场景：
- 在 HTTP 中间件或日志埋点这类高频路径里反复创建带 timeout 的 context
- 把
ctx, cancel := context.WithTimeout(...)写在 for 循环里，却漏掉defer cancel() - 在 goroutine 里启动带 timeout 的 context，但主逻辑提前 return，
cancel()永远没机会执行
后果是：高并发下堆积数百甚至上千个待触发 timer，Go runtime 定时器管理负载飙升，GC 压力增大，P99 延迟明显抬升。
为什么 defer cancel() 漏掉就等于埋雷？
漏掉 defer cancel() 是最隐蔽、最常被忽视的性能隐患之一。它不报错，也不 panic，但会在后台持续泄漏三样东西：
立即学习“go语言免费学习笔记（深入）”；
- 一个 goroutine（timer 启动的内部协程）
- 一块堆内存（timer 结构体 + context 树节点）
- 一次定时器轮询资源（runtime timer heap 插入/删除开销）
长期运行的服务会出现：
-
runtime.NumGoroutine()缓慢但稳定上涨 -
pprof heap中大量timer和context.cancelCtx实例 - GC pause 时间逐渐变长，尤其在大内存机器上更明显
实操建议：
- 所有
context.WithCancel/WithTimeout/WithDeadline必须配对defer cancel() - 若逻辑分支多（如 if/else/return），把
cancel()提前到函数顶部，用defer func(){ cancel() }()包一层更稳妥 - 在测试中加断言：启动 goroutine 前记录
runtime.NumGoroutine()，结束后检查是否恢复
HTTP 请求里传 r.Context() 给后台 goroutine 为什么危险？
因为 r.Context() 的生命周期由 HTTP 连接控制：客户端断开、超时、主动 cancel，都会立刻触发 ctx.Done()。一旦你把它传给后台 goroutine（比如发消息、写日志、异步通知），任务大概率被中途掐断。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型错误代码：
go func() {
err := publish(r.Context(), response) // ← 这里可能刚执行一半就被 cancel
}()问题不止于失败——更严重的是：
- publish 可能持有数据库连接、HTTP client、文件句柄等资源，未完成清理就退出 → 资源泄漏
- 如果 publish 内部还有子 goroutine 或重试逻辑，它们也会跟着被 cancel，状态不一致风险陡增
- 日志显示约 30% 的后台任务因此异常退出（来自真实压测数据）
正确做法：
- 后台任务改用
context.Background()或独立的、带自己 timeout 的 context - 若需 trace ID 等元信息，用
context.WithValue(context.Background(), key, val)显式注入，别复用请求 context - 真要联动生命周期？加个 channel 或 sync.WaitGroup 控制，而不是靠 cancel 信号“硬杀”
什么时候该用 WithValue？什么时候不该？
context.WithValue 只适合传轻量、只读、请求级元数据，比如 traceID、userID、reqID。它不是通用参数传递机制，更不是替代函数参数的捷径。
滥用表现和风险：
- 传大型结构体（如
*sql.DB、map[string]interface{}、用户完整 profile）→ 上下文对象臃肿，GC 压力翻倍 - 在中间层硬编码
context.WithValue(ctx, "config", cfg)→ 调用链越深，context 树越胖，查找Value()的时间复杂度线性增长 - 用
WithValue传业务主参数（如"user"、"order"）→ 类型不安全、IDE 无法跳转、单元测试难 mock
实操边界：
- ✅ 允许：
ctx = context.WithValue(r.Context(), traceIDKey, r.Header.Get("X-Trace-ID")) - ❌ 禁止：
ctx = context.WithValue(ctx, "db", db)或ctx = context.WithValue(ctx, "user", hugeUserStruct) - 替代方案：需要共享对象，就通过函数参数或 struct 字段传；需要全局配置，走依赖注入或包级变量（确保线程安全）
真正难的不是“怎么用”，而是“忍住不用”。多数时候，删掉一行 context.WithValue，比加十行逻辑更有效。
