context.withvalue 返回新 context，原 context 不变；必须显式传递返回值，否则下游拿不到 traceid；key 应用自定义未导出类型，避免字符串冲突；traceid 需 header 与 context 双载体。
context.WithValue 传 traceID 为什么总拿不到？
因为 context.WithValue 返回的是新 context，原 context 不变；不把返回值一路往下传，下游根本收不到。常见写法是 handler 里改了 context 却没传给下一层函数，或者中间件里忘了用 next.ServeHTTP 包一层带新 context 的 responseWriter。
- 必须显式把
ctx作为参数传给所有依赖它的函数（比如日志、DB 调用、HTTP client） - 不要在全局变量或闭包里缓存旧 context —— 它不会自动更新
- key 类型推荐用自定义未导出类型（如
type ctxKey string），避免字符串 key 冲突
traceID 应该存在 context 里还是 HTTP Header 里？
两个都得有：Header 是传输载体，context 是运行时载体。HTTP 入口处从 r.Header.Get("X-Trace-ID") 读出来，再用 context.WithValue 塞进 context；出口处再从 context 取出来写回响应 Header 或日志。只靠 Header 无法穿透 goroutine、channel、异步任务等边界。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 入口示例：
ctx = context.WithValue(r.Context(), traceKey, traceID) - 取值必须用同一 key 类型：
traceID := ctx.Value(traceKey).(string)（注意类型断言 panic 风险） - 别用
string当 key，否则不同包里同名字符串 key 会互相覆盖
WithValue 性能差吗？什么时候该换方案？
单次 WithValue 开销很小，但深层嵌套（比如 10+ 层）或高频调用（每毫秒数百次）时，底层 map 查找和接口转换会有可观开销。更严重的是可维护性：到处 ctx.Value(key) 让调用链路隐式依赖，改个 key 就得全局搜。
- 高频路径（如日志打点）建议提前解包：
traceID := ctx.Value(traceKey).(string)一次，传参进去 - 跨服务传播优先走标准 header（
traceparent），别自己造X-Trace-ID - 如果发现多个地方都要取同样几个值，考虑封装成 struct 传参，而不是反复查 context
为什么日志里 traceID 有时是空的？
最常见原因是 goroutine 分叉后没传递 context。比如 go func() { log.Info(ctx) }()，这个 ctx 是外层变量，但 goroutine 启动时可能外层函数已 return，ctx 已被 cancel 或丢弃。另一个原因是中间件顺序错了——鉴权中间件覆盖了 trace 中间件的 context。
- 启动 goroutine 必须显式传 context：
go func(ctx context.Context) { ... }(ctx) - 用
context.WithTimeout或WithCancel创建子 context 时，记得也带上 traceID：childCtx := context.WithTimeout(parentCtx, d)，parentCtx 已含 traceID 才行 - 检查中间件注册顺序，确保 trace 注入在最外层，且其他中间件调用
next.ServeHTTP时传的是新 context
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
