context.Context 是日志追踪的起点，因其能自然贯穿HTTP handler、gRPC方法、数据库调用等各层，必须从中注入并传递trace_id、span_id等标识，避免使用全局logger或忽略cancel/timeout语义导致上下文失效。
为什么 context.Context 是日志追踪的起点
微服务中请求跨多个服务流转，单靠时间戳或日志行号无法关联同一请求的所有日志。Go 标准库的 context.Context 是唯一能自然贯穿 HTTP handler、gRPC 方法、数据库调用等各层的载体，必须从这里注入和传递追踪标识（如 trace_id、span_id）。
常见错误是只在 HTTP 入口生成 trace_id，但未通过 context.WithValue() 注入到后续调用链；更糟的是在 goroutine 中直接拷贝 context 而忽略 cancel/timeout 语义，导致内存泄漏或上下文失效。
- 始终用自定义 key（如
type ctxKey string; const traceIDKey ctxKey = "trace_id"）避免与其他库冲突 - HTTP 中间件里用
r.Context()获取原始 context，再context.WithValue()注入trace_id，最后传给next.ServeHTTP() - 不要用
context.Background()或context.TODO()启动新 goroutine —— 应显式context.WithCancel(parent)并管理生命周期
如何让 log/slog 自动携带 trace_id
Go 1.21+ 的 slog 支持 slog.Handler 接口定制，可拦截每条日志并注入当前 context 中的 trace_id。关键不是“加字段”，而是确保 handler 能从 context 提取值 —— 这要求 logger 必须与 context 绑定，不能全局复用一个 *slog.Logger 实例。
典型误用：定义全局 var logger = slog.New(...)，然后在 handler 里试图“临时加字段”，结果所有日志都混在一起，无法区分请求。
立即学习“go语言免费学习笔记（深入）”；
- 为每个请求创建带 context 的 logger：
logger := slog.With("trace_id", getTraceID(r.Context())) - 自定义
slog.Handler时，在Handle()方法内调用ctx.Value(traceIDKey)（需把 context 以某种方式传入 handler，例如通过HandlerOptions扩展或闭包捕获） - 若用第三方日志库（如
zerolog或logrus），同样要避免全局 logger；推荐用With().Logger()派生子 logger，并在中间件中注入trace_id
gRPC 请求如何透传 trace_id 到下游服务
gRPC 默认不自动转发 context metadata，必须手动提取、透传。上游服务从 HTTP header（如 X-Trace-ID）解析出 trace_id 后，要写入 gRPC metadata 并随请求发出；下游服务则需从 incoming metadata 中读取并注入自己的 context。
容易被忽略的是：gRPC client 拦截器里若未显式调用 metadata.AppendToOutgoingContext()，trace_id 就不会出现在 wire 上；而 server 拦截器若未用 metadata.FromIncomingContext() 解析，下游日志就仍是空的。
- client 拦截器示例：
func loggingClientInterceptor(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error { if tid, ok := ctx.Value(traceIDKey).(string); ok { md := metadata.Pairs("x-trace-id", tid) ctx = metadata.AppendToOutgoingContext(ctx, md...) } return invoker(ctx, method, req, reply, cc, opts...) } - server 拦截器中，用
md, _ := metadata.FromIncomingContext(ctx)取值，再context.WithValue()注入新 context - 注意 metadata key 名称统一（如全小写加连字符），gRPC 会自动转为 HTTP/2 小写格式，大小写不一致会导致丢失
日志聚合时为何 trace_id 总对不上
最常出现的现象是：前端看到一个 trace_id，但查 ELK 或 Loki 时，只有部分服务的日志有该 ID，其余为空。根本原因不是日志没打，而是 trace_id 在某一层被覆盖、丢弃或格式不一致。
比如 HTTP 中间件生成了 trace_id，但调用 DB 时用了另一个 goroutine 且未传 context；或者 gRPC server 拦截器读取 metadata 成功，却忘了把 trace_id 写进自己的 logger；又或者不同服务用了不同生成逻辑（UUID v4 vs nanoid vs 时间戳+随机数），导致长度/字符集不兼容日志系统正则提取规则。
- 所有中间件、handler、client 调用点都应做防御性检查：
if tid == "" { tid = generateTraceID() } - 统一使用
github.com/google/uuid的NewString()生成，避免自研算法引入不一致 - 在日志输出前加一行 debug 日志：
slog.Debug("trace_id resolved", "id", getTraceID(ctx))，快速定位丢失环节
真正难的不是加字段，而是确保它从第一个字节进入系统，到最后一个 SQL 查询完成，全程不被任何中间层剥离或重置。
