context.context 不保证 trace id 全局唯一，因其仅传递值而不生成或管理 trace id；需在请求入口统一生成、全程透传，并显式跨 goroutine 和跨服务注入。
为什么 context.Context 本身不保证 trace ID 全局唯一
Go 标准库的 context.Context 只负责传递请求生命周期内的值和取消信号，它不生成、不管理 trace ID。你传进去什么 ID，它就传什么——如果多个 goroutine 并发处理同一个请求但各自调用 uuid.New()，就会产生多个 ID；如果中间件没把 ID 注入 context，下游就根本拿不到。真正需要的是：在请求入口统一生成一次、全程透传、跨服务可对齐。
用 middleware 在 HTTP 入口注入 trace ID 的正确姿势
别在 handler 里临时生成 trace ID，必须在最外层中间件完成初始化并写入 context.WithValue。否则中间件链（如日志、鉴权、限流）可能读不到，或者重复生成。
- 优先使用
req.Header.Get("X-Request-ID")或"Traceparent"（W3C Trace Context 格式），有则复用，避免破坏链路连续性 - 没有时才用
github.com/google/uuid生成uuid.Must(uuid.NewUUID()).String()，确保格式稳定（短横线分隔） - 务必用自定义 key（如
type ctxKey string; const traceIDKey ctxKey = "trace_id"），避免和第三方库 key 冲突 - 不要用
context.WithValue(ctx, "trace_id", id)这种字符串 key —— 类型不安全，容易拼错
跨 goroutine 和跨服务时 trace ID 怎么不丢
Go 的 context.Context 默认不跨 goroutine 传播，显式启动的新 goroutine 拿到的是原始 context，不是带 trace ID 的那个。HTTP 客户端发请求时，header 也不会自动带上 trace ID，除非你手动注入。
- 新 goroutine 必须显式传入带 trace ID 的
ctx：go processItem(ctx, item)，而不是go processItem(context.Background(), item) - 调用下游 HTTP 服务前，用
req = req.WithContext(ctx)确保 context 关联，再用req.Header.Set("X-Request-ID", getTraceID(ctx))注入 header - 如果用
net/http.Client，建议封装一个DoWithContext(ctx, req)方法，统一处理 trace header 注入和超时继承 - gRPC 场景下，用
metadata.AppendToOutgoingContext(ctx, "trace-id", id)，服务端用metadata.FromIncomingContext(ctx)提取
用 uber-go/zap 打印 trace ID 但日志里还是看不到？
zap 的 With() 是一次性绑定，不会自动从 context 提取 trace ID。如果你每个 log 语句都手动写 log.Info("msg", zap.String("trace_id", id))，不仅重复，还容易漏。
- 用
zap.AddStacktrace()配合zap.Fields()不解决根本问题——它不读 context - 正确做法是构建一个带 trace ID 的 logger 实例：
logger := log.With(zap.String("trace_id", getTraceID(ctx)))，然后在该请求生命周期内只用这个 logger - 更省事的是用
zapr（klog 适配器）或自定义zapcore.Core，在WriteEntry阶段自动从 context 提取 trace ID（需配合context.WithValue使用） - 注意：不要在全局 logger 上
.With()，那会污染所有请求；必须 per-request 构造
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
