Go中可用context.Context模拟MDC：入口解析trace_id注入context，下游显式传递，日志库（如zap）封装wrapper自动提取并注入字段，gRPC需通过metadata+拦截器透传，goroutine须派生新context防覆盖或泄漏。
Go 里没有 MDC，但可以用 context.Context 模拟等效行为
Java 的 MDC（Mapped Diagnostic Context）靠线程局部变量自动透传日志上下文，Go 没有线程（goroutine）局部存储机制，硬搬 MDC 会踩坑。真正可行的路径是把追踪 ID、请求 ID 这类字段塞进 context.Context，再让日志库（如 zap、logrus）在写日志时主动从 context 中提取。
常见错误现象：log.Printf("req_id=%s", reqID) 手动拼接——一旦中间加了 goroutine 或调用链变深，reqID 就断了；或者用全局 map + goroutine id 做“伪 MDC”，结果竞态、内存泄漏、GC 压力大。
- 所有入口（HTTP handler、gRPC server 方法、消息消费函数）必须从请求中解析出
trace_id/request_id，并用context.WithValue()注入context.Context - 下游调用（DB 查询、HTTP client 请求、其他微服务调用）必须显式传递该
context，不能用context.Background()替代 - 日志库需支持
context.Context注入：例如zap配合zap.AddCallerSkip(1)和自定义zapcore.Core，或用logrus.WithContext(ctx).Info()（需启用logrus.WithContext插件）
用 zap + context 实现 trace_id 自动注入
zap 本身不读 context，必须自己封装一层。否则每次打日志都得手动 logger.With(zap.String("trace_id", getTraceID(ctx))).Info(...)，极易遗漏。
使用场景：HTTP handler 中已通过 middleware 解析出 X-Request-ID 或 traceparent，需要它出现在每条日志里，包括中间件、service 层、repo 层的日志。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义 key 类型避免
contextkey 冲突：type ctxKey string; const traceIDKey ctxKey = "trace_id" - 写一个 wrapper logger：接收
context.Context，从中取trace_id，再调用zap.Logger.With()构造带字段的新 logger - 示例：
logger := NewTraceLogger(zap.L()).With(ctx); logger.Info("db query start")→ 自动带上"trace_id":"abc123" - 注意性能：
With()是浅拷贝，开销小；但频繁构造新 logger 仍比复用 root logger 略重，建议在 request scope 内复用一次构造好的 logger
gRPC 调用链中 trace_id 透传失败的典型原因
HTTP 场景下 header 透传较直观，gRPC 的 metadata 机制容易被忽略或误用，导致下游收不到 trace_id，链路断裂。
常见错误现象：客户端写了 metadata.Pairs("trace-id", tid)，但服务端 grpc.ServerOption 没配拦截器，或拦截器里没调用 md.Get("trace-id") 并注入 context。
- 客户端必须用
grpc.Header()或grpc.Trailer()显式发送 metadata，不能只靠context.WithValue()—— 它不出网 - 服务端必须注册
grpc.UnaryInterceptor，在拦截器中用metadata.FromIncomingContext(ctx)取值，并用context.WithValue()注入新 context 后传给 handler - 参数差异：
metadata.Pairs()的 key 会自动转为小写，所以服务端应查"trace-id"而非"Trace-ID"；若用 OpenTelemetry，优先走otelgrpc.Interceptor，它自动处理 W3C traceparent - 兼容性影响：gRPC-Web 或某些网关（如 Envoy）可能 strip 自定义 metadata，需确认其配置是否允许透传
trace-id
并发 goroutine 中 context 泄漏或覆盖导致日志错乱
多个 goroutine 共享同一个 context 并反复 WithValue()，会导致字段被覆盖；或者 goroutine 持有老的 context 不释放，日志打出过期的 trace_id。
使用场景：HTTP handler 启动多个子 goroutine 处理异步任务（发邮件、写缓存），每个任务需独立 trace 上下文，但又想继承父请求的 trace_id。
- 不要在 goroutine 内直接修改传入的
ctx：ctx = context.WithValue(ctx, k, v)是危险的，上游可能还在用原ctx - 正确做法：在启动 goroutine 前，先派生新
context——go func(ctx context.Context) { ... }(context.WithValue(parentCtx, k, v)) - 若子任务需独立 trace（比如发邮件属于另一个业务链路），应生成新
trace_id，而不是复用 HTTP 请求的；可用otel.TraceIDFromHex(...)或简单uuid.New().String() - 容易被忽略的点：
time.AfterFunc、http.TimeoutHandler内部启动的 goroutine，常被遗忘传context，它们的日志会丢失 trace 上下文
最麻烦的不是怎么加 trace_id，而是怎么确保它在每一层都不被丢、不被错、不被污染——尤其是跨 goroutine、跨 goroutine pool、跨中间件的时候。context 传参看着简单，漏一次，整条链就断了。
