不能直接用 goroutine 局部变量存 traceid，因为 goroutine 不共享栈、无法自动透传值，且全局或包级变量会导致并发请求间 id 串扰；必须通过 context.withvalue（键为私有 struct{} 类型）注入，并在启动新 goroutine 时显式传递该 context。
为什么不能直接用 goroutine 局部变量存 TraceID
因为 Go 的 goroutine 之间不共享栈，也没办法在任意嵌套调用中自动透传一个值——你不能靠函数参数层层往下传（太重），也不能靠全局变量（会跨请求污染）。常见错误是把 traceID 存在某个包级变量里，结果并发请求一上来，A 请求的 ID 被 B 请求覆盖，日志全串了。
真正可行的路径只有一条：用 context.Context 携带，并在每次新建 goroutine 时显式传递它。
如何用 context.WithValue 正确注入 TraceID
context.WithValue 是标准做法，但要注意键必须是不可比较的类型（避免被误用为字符串字面量），否则不同包里用 "trace_id" 当 key，会导致取不到值。
- 定义私有 key 类型：
type traceIDKey struct{}，然后用context.WithValue(ctx, traceIDKey{}, "abc123") - 提取时必须用同一个 key 类型：
id, ok := ctx.Value(traceIDKey{}).(string)—— 这里traceIDKey{}看似新建，实则因是空结构体，底层地址相同，能命中 - 千万别用
string或int做 key，比如ctx.Value("trace_id")，Go 1.21+ 会静默失败或返回 nil
HTTP 中间件怎么从 header 注入并向下传递
微服务入口通常是 HTTP handler，TraceID 一般来自上游 X-Trace-ID 或 traceparent。关键在于：中间件必须返回 *新的* context，并让后续 handler 使用它，而不是修改原 http.Request 的 Context() 后就不管了。
正确写法：
func TraceIDMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
traceID := r.Header.Get("X-Trace-ID")
if traceID == "" {
traceID = generateTraceID() // 如 uuid.New().String()
}
ctx := context.WithValue(r.Context(), traceIDKey{}, traceID)
r = r.WithContext(ctx) // ← 必须重新赋值 r！
next.ServeHTTP(w, r)
})
}
漏掉 r.WithContext(ctx) 是高频坑——后续 r.Context() 还是老的，ID 就断了。
新 goroutine 启动时怎么确保 TraceID 不丢失
任何显式启动的 go func() { ... }() 都不会自动继承父 goroutine 的 context；必须手动传进去。最简方式是闭包捕获，但要注意变量逃逸风险。
- 安全写法（推荐）：
go func(ctx context.Context) { /* use ctx.Value(traceIDKey{}) */ }(r.Context()) - 危险写法：
go func() { /* 直接用外层 r.Context() */ }()—— 外层 handler 返回后，r可能被回收，Context变成background或已取消 - 如果要起多个 goroutine 并等它们完成，用
errgroup.Group+ctx，它内部会自动传播 cancel 和 value
跨 goroutine 的日志打点、HTTP client 调用、DB 查询，都得从传入的 ctx 里取 traceID，而不是试图从当前 goroutine 找“全局上下文”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
