log.Printf无法支撑微服务链路追踪，因其缺乏全局唯一且透传的trace_id，导致跨服务请求日志上下文丢失；需结合context.Context与zap自动注入trace_id，并统一用OpenTelemetry propagator处理HTTP/gRPC协议透传，采样应基于trace_id哈希而非随机。
为什么 log.Printf 无法支撑微服务链路追踪
单体应用里用 log.Printf 打日志没问题，但微服务一拆，一次请求跨多个服务（比如 gateway → auth → user → order），原始日志就彻底失去上下文关联。你查 order 服务里一条报错日志，根本不知道它来自哪个用户、哪个前端请求、甚至不知道上游 auth 是否已返回失败。
根本原因在于：日志缺少唯一且透传的链路标识。没有这个标识，ELK 或 Loki 里再好的检索能力也串不起完整路径。
必须让每次请求从入口开始携带一个全局唯一的 trace_id，并在所有下游调用和日志中自动注入，而不是靠每个服务手动拼接字符串。
用 context.Context + zap 实现透传与自动注入
Go 生态里最轻量可靠的方案是结合 context.Context 存储 trace_id，再通过 zap 的 Logger.With() 或自定义 Core 实现日志字段自动携带。关键不是“加字段”，而是“不侵入业务逻辑”。
立即学习“go语言免费学习笔记（深入）”；
- 入口（如 HTTP handler）从请求头（
X-Trace-ID或traceparent）提取或生成trace_id，塞进ctx：ctx = context.WithValue(r.Context(), "trace_id", tid)
- 所有下游调用（HTTP / gRPC）必须把
ctx传下去，并在请求头中透传trace_id -
zap.Logger不直接复用全局实例，而是基于ctx动态构造带 trace 字段的 logger：logger := zap.L().With(zap.String("trace_id", getTraceID(ctx))) - 避免用
context.WithValue存任意字符串——定义类型安全的 key，比如type ctxKey string; const traceIDKey ctxKey = "trace_id"
gRPC 和 HTTP 之间 trace_id 如何对齐
混合架构（HTTP 入口 → gRPC 调用下游）最容易出问题：HTTP 头里的 X-Trace-ID 到了 gRPC 侧没被识别，或者 gRPC 的 traceparent 格式不被 HTTP 服务理解，导致链路断裂。
必须统一解析逻辑，推荐用 go.opentelemetry.io/otel/propagation 的 B3 或 W3C propagator，它能同时处理两种协议的 header：
- HTTP 服务收到请求后，用
propagator.Extract(ctx, propagation.HeaderCarrier(r.Header))解析trace_id - 发起 gRPC 调用前，用
propagator.Inject(ctx, metadata.MD{...})把 trace 信息写入metadata - 别自己解析
traceparent字符串——格式细节（如 sampling flag、parent_id）容易漏判，直接交由标准 propagator
如果不用 OpenTelemetry，至少保证所有服务都用同一套解析函数，而不是各自实现一个 getTraceIDFromHeader。
日志采样与 trace_id 冲突风险
高并发下全量打 trace 日志会撑爆磁盘，所以常配采样率（比如 1%）。但采样不能只看随机数——如果只采样 order 服务而跳过 user，整条链路依然不可见。
真正有效的做法是「基于 trace_id 哈希采样」：对 trace_id 做哈希取模，比如 hash(trace_id) % 100 表示 1% 采样。这样同一条链路的所有日志要么全被采，要么全被丢，不会碎片化。
注意点：
- 别用
time.Now().UnixNano()或rand.Intn()做采样判断——这会让同一次请求在不同服务里采样结果不一致 - 如果用了 OpenTelemetry，直接配置
ParentBased(TraceIDRatioBased(0.01))，它默认就是 trace_id 哈希采样 - 测试阶段建议关掉采样，否则本地联调时根本看不到完整链路
链路追踪失效往往不是因为没加 trace_id，而是透传断在某一层 header、采样逻辑不一致、或者 logger 没绑定 ctx——这三个点比选什么日志库重要得多。
