context.WithValue在热路径中性能极差，因其底层为O(n)链表结构，高频调用导致新建节点、遍历开销激增，应改用sync.Pool复用结构体透传关键字段。
热路径里用 context.WithValue 传上下文，性能掉得比没加缓存还明显——这不是你代码写错了，是它本来就不该出现在每毫秒调用几十次的地方。
为什么 context.WithValue 在热路径里会拖慢整个服务
它底层是链表结构，每次 WithValue 都要新建一个节点；每次 Value 查找都要从头遍历，O(n) 时间复杂度。在日志打点、指标埋点、权限校验这类高频调用点里，一次请求走 5 层中间件，就可能新建 5 个 context 节点 + 做 10 次链表遍历。pprof 里常看到 context.valueCtx.Value 占 CPU top3，就是这个原因。
- 别把它当“轻量全局变量”用，它不是为高频读写设计的
- 值类型越复杂（比如 struct 或 map），拷贝开销越大，GC 压力也越明显
- 一旦嵌套深（比如中间件套中间件再套异步任务），链表长度不可控，延迟毛刺直接上 P99
用 sync.Pool + 自定义结构体替代 context.WithValue
把真正需要透传的几个关键字段（如 trace_id、user_id、req_id）抽出来，塞进一个固定结构体里，用 sync.Pool 复用实例。避免每次请求都 new + GC，也绕过 context 链表查找。
- 结构体必须是值类型，字段尽量用
string或int64，别嵌指针或 map -
sync.Pool.New返回的是全新结构体，不能复用已有实例（否则脏数据污染后续请求） - 每次
Get后必须显式重置字段，例如ctx.traceID = ""，不能只靠 GC 清理 - HTTP handler 入口
defer pool.Put(ctx)，确保生命周期可控
示例：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
type RequestContext struct {
traceID string
userID int64
reqTime int64
}
var ctxPool = sync.Pool{
New: func() interface{} {
return &RequestContext{}
},
}
哪些地方必须保留 context.Context，哪些可以砍掉
不是所有“传东西”的场景都要上下文。分清楚语义：控制生命周期和取消信号的，必须用 context.Context；只为了读几个字段的，优先走池化结构体。
- 数据库查询、HTTP 调用、channel select —— 必须传
ctx，用于超时/取消 - 日志写入、指标上报、AB 分组判断 —— 改用
*RequestContext，不依赖Value()查找 - 中间件之间传参数（比如 JWT 解析结果）—— 用局部变量或函数参数传递，别塞 context
- 异步任务启动时，如果只是转发几个 ID 字段，用结构体序列化后传参；如果需响应上游取消，则仍需带原始
ctx并做WithTimeout
容易被忽略的兼容性坑：goroutine 泄漏 + 池污染
最隐蔽的问题不是慢，而是错——用了 sync.Pool 却没清空字段，或者没 Put 回去，导致下个请求拿到脏数据；又或者在 goroutine 里忘了 defer Put，导致池子慢慢耗尽。
- 永远不要在 long-running goroutine（比如定时任务）里 Get/Put，
sync.Pool的回收节奏依赖于主 goroutine 的 GC 触发频率 - 结构体里别存闭包、接口或指针，除非你能 100% 控制其生命周期
- 上线前跑一遍 pprof heap，确认
RequestContext实例数稳定，没有持续增长
真正的轻量，不是少写几行代码，而是让每个字节都在它该在的位置上干活。热路径里多一次内存分配，就多一次 GC 停顿风险；多一次链表遍历，就多一分延迟不确定性。选对工具，比优化工具更重要。
