必须用私有struct{}类型作key，因string key跨包不相等导致ctx.value返回nil；需在http中间件注入、goroutine显式传参、http/grpc手动透传header/metadata，漏一处即断链。
为什么直接用 context.WithValue 埋 trace ID 容易出错
因为 context.WithValue 不做类型安全检查，且值键（key）若用 string 类型，跨包传递时极易冲突或被覆盖。比如中间件 A 存了 "trace_id"，中间件 B 也用同名 key 写入，下游就拿不到原始 trace ID。
- 必须用自定义类型作 key，例如
type traceKey struct{}，避免字符串 key 冲突 - 每次调用
context.WithValue都生成新 context，但若上游没传 context 或漏传，下游ctx.Value()就返回nil - HTTP header 中的 trace ID（如
X-Trace-ID）若为空，不应 fallback 到随机生成再塞进 context——这会导致同一请求在不同中间件里拿到两个 ID
如何从 HTTP 请求头提取并透传 trace ID
标准做法是优先读取 X-Request-ID 或 traceparent（W3C Trace Context），没有时才生成新的。关键在于：生成只做一次，且必须在最外层 handler 开始时完成。
- 用
http.Header.Get("X-Trace-ID")读取，但注意大小写——Go 的http.Header默认 normalize 为首字母大写，实际可匹配任意大小写 - 若 header 为空，调用
generateTraceID()（推荐用uuid.New().String()或更轻量的rand.Intn+ 时间戳拼接） - 生成后立即用
context.WithValue(ctx, traceKey{}, traceID)注入，后续所有 handler、service 层都从该 ctx 取值，不再重复生成
怎样让 trace ID 自动注入日志字段
不是每条日志都手动加 trace_id=xxx，而是靠 logger 实例绑定 context 中的 trace ID。前提是 logger 支持 context-aware 字段注入，比如 log/slog 或 zap。
- 用
slog.With("trace_id", getTraceID(ctx))包一层，但别在每个 log 调用前都算——getTraceID应缓存结果，避免多次ctx.Value()查找 - 如果用
zap，推荐封装zap.AddCallerSkip(1)+zap.String("trace_id", getTraceID(ctx))，不要依赖全局 logger - 切记：HTTP middleware 中 logger 实例应随 request context 创建，不能复用全局实例，否则 trace ID 会串
goroutine 泄漏时 trace ID 还能查吗
不能。goroutine 启动时若没显式传入带 trace ID 的 context（比如用 go fn() 而非 go fn(ctx)），一旦原 request 结束、context cancel，该 goroutine 就彻底丢失 trace 上下文。
- 异步任务必须显式接收并传递 context，例如
go processAsync(ctx, data) - 数据库查询、RPC 调用等下游操作，要确保 driver/client 支持 context 透传（如
db.QueryContext(ctx, ...)） - 第三方库不支持 context？只能退而求其次：在 goroutine 启动前把 trace ID 提取出来，作为参数传入，再手动注入日志字段
真正难的不是生成 ID，而是保证它从入口到最后一行日志、最后一个 goroutine 都没断掉。漏掉一处，整条链就断了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
