context.WithValue不能跨服务传递traceID，因为Context仅限进程内有效，HTTP/gRPC请求需通过Header或metadata显式传递traceID，并在入口提取、出口注入。
为什么 context.WithValue 不能直接跨服务传递日志 traceID
Go 的 context.Context 是进程内传递的，HTTP 请求进来的那一刻，服务 A 的 ctx 就和下游服务 B 完全无关了。你用 context.WithValue(ctx, key, "trace-123") 塞进去的值，不会自动出现在服务 B 的 ctx 里——它根本没被序列化、没被发出去。
真正要做的，是把 traceID 从 context 提取出来，塞进 HTTP Header（比如 X-Trace-ID），再在下游服务收到请求时，从 Header 里读出来，重新构造成新的 context。
常见错误现象：
– 日志里 A 服务有 traceID，B 服务全是空或默认值
– 用 log.Printf 打印 ctx.Value(traceKey) 在中间件里是空的
– 没意识到 http.RoundTripper 和 http.Handler 是两个独立上下文边界
如何用 middleware 注入和提取 traceID（基于 net/http）
标准做法是在入口处（Handler）从 Header 读 traceID，写入新 context；在出口处（Client）从当前 context 取值，注入到 Request Header。
- 入口中间件：检查
X-Trace-ID，若不存在则生成新值（如uuid.New().String()），调用req = req.WithContext(context.WithValue(req.Context(), traceKey, traceID)) - 出口封装：写一个带 context 的 HTTP client 方法，例如
DoWithContext(ctx context.Context, req *http.Request) (*http.Response, error)，内部执行req.Header.Set("X-Trace-ID", ctx.Value(traceKey).(string)) - 注意：key 必须是全局唯一变量（
var traceKey = struct{}{}），不能用字符串字面量，否则ctx.Value("trace-id")会拿不到
log/slog 如何绑定 traceID 到每条日志（Go 1.21+）
slog 本身不自动读 context，但支持 slog.With 和 slog.Handler 的 Handle 方法接收 context.Context（需自定义 Handler）。更轻量的做法是：在中间件里把 traceID 提前塞进 slog.Logger 实例，而不是每次日志都查 context。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 推荐方式：在 HTTP handler 内部创建带字段的 logger：
logger := slog.With("trace_id", traceID)，然后传给业务逻辑 - 避免：在全局 logger 上反复调用
slog.With而不复用，会创建大量临时 map - 如果用第三方日志库（如 zerolog、zap），它们通常自带
ctx.Context提取能力，但底层仍依赖你先把 traceID 放进 context —— 这步不能跳
gRPC 场景下怎么传？别漏掉 metadata
gRPC 不走 HTTP Header，而是用 metadata.MD。客户端发请求前要显式把 traceID 写进 metadata：md := metadata.Pairs("x-trace-id", traceID); ctx = metadata.NewOutgoingContext(ctx, md)。服务端则用 metadata.FromIncomingContext(ctx) 提取。
- gRPC 的 context 传递比 HTTP 更“透明”，但 metadata 默认不透传，必须手动做
- 注意键名大小写：gRPC metadata 键名强制小写加短横线（
x-trace-id），不是X-Trace-ID - 如果混用 gRPC 和 HTTP（比如网关层），建议统一用小写格式，避免两边逻辑不一致
最易被忽略的一点：traceID 的生成时机必须在第一个入口（如 HTTP handler 或 gRPC server interceptor）就完成，且全程只生成一次。任何中间环节重复生成，链路就断了。
