可靠做法是用结构化日志（如zap）配合context.context透传traceid：http入口解析请求头后立即写入ctx，日志器自动从中提取trace_id字段，中间件需显式传递新ctx，出站请求须注入traceparent头，禁用log.printf等非结构化方式。
TraceID 怎么注入到 Go 日志里才不会丢
Go 默认日志（log）不带上下文，每次 log.Println 都是新行、无 TraceID。直接在日志前拼 traceID 字符串看似简单，但并发下容易串、中间件里漏传、HTTP 请求还没进 handler 就要打日志——这些地方都拿不到 traceID。
真正可靠的做法是用结构化日志 + 上下文透传。推荐 zap 配合 context.Context：把 traceID 写进 context，再让日志器从 context 里取。
- 别用全局变量存
traceID——goroutine 不安全，中间件链一长就错乱 - HTTP 入口（如
http.Handler）必须在解析请求头（比如X-Trace-ID或traceparent）后立即塞进ctx，用context.WithValue或更推荐的context.WithContext封装 -
zap.Logger要封装一层，支持从context.Context自动提取traceID字段，例如用zap.AddCallerSkip(1)避免日志里显示封装函数名
为什么 zap.SugaredLogger 默认不带 TraceID
SugaredLogger 是 zap.Logger 的语法糖，本身不感知 context。它只负责格式化和输出，字段全靠你手动传或提前绑定。如果你看到日志里没 traceID，大概率是用了 logger.Info("msg") 这种无字段调用，或者没在 logger 初始化时绑定 traceID 字段。
正确姿势不是改 SugaredLogger，而是换回 zap.Logger 做结构化埋点，或给 SugaredLogger 包一层：
立即学习“go语言免费学习笔记（深入）”；
func (l *Logger) InfoCtx(ctx context.Context, msg string, fields ...interface{}) {
traceID := getTraceIDFromCtx(ctx)
l.sugar.With("trace_id", traceID).Infof(msg, fields...)
}
- 别在每处
Infof前手动加"trace_id", traceID——重复、易漏、难维护 - 如果用了
zerolog，同理：必须用ctx.With().Logger()派生新 logger，不能复用顶层实例 - 注意
traceID字段名统一，比如都叫trace_id（下划线），别混用traceId或TraceID，否则 ELK 或 Jaeger 查询时对不上
HTTP 中间件里怎么保证 TraceID 从头传到尾
常见错误是：中间件 A 解析了 X-Trace-ID 并写入 context，但中间件 B 没用 next.ServeHTTP(w, r.WithContext(ctx)) 把新 ctx 传下去，导致后续 handler 和日志全用默认空 ctx。
另一个坑是用了第三方中间件（比如 cors、gzip），它们不主动透传 context，得检查源码或自己 wrap 一层。
- 所有中间件必须显式调用
r = r.WithContext(newCtx)，再传给next.ServeHTTP - 推荐用
go.opentelemetry.io/otel/propagation解析traceparent，兼容 W3C 标准，比手撕X-Trace-ID更健壮 - 如果服务要发 HTTP 出去（比如调下游微服务），记得用
propagators.Extract+propagators.Inject把traceID写进请求头，否则链路断在第一跳
log.Printf 直接打 TraceID 会有什么后果
能打出来，但基本等于白打：没有结构、无法过滤、查日志时得 grep 整行；更严重的是，一旦某条日志里 traceID 写错了（比如拼错变量名、漏判空），整条链路就不可关联；而且 log.Printf 不支持字段级别采样、异步写入、滚动切割等生产必需能力。
哪怕只是临时调试，也建议至少用 fmt.Printf("[trace_id=%s] %s\n", traceID, msg)，保持字段格式一致，方便后期正则提取。
- 线上环境禁用
log.Printf埋点——它和fmt.Printf一样，是同步阻塞 I/O，高并发下容易拖慢整个 handler - 如果非要用标准库，至少用
log.SetPrefix统一加[trace_id=...]，但注意：这个 prefix 是全局的，goroutine 之间会互相覆盖 - 最轻量的兜底方案：用
context.Context+log.Logger自定义Output，在 Write 方法里自动 prepend traceID，不过这已经接近重写日志器了
TraceID 不是打进去就完事，关键在“不丢、不错、可传递”。最容易被忽略的是出站请求的 header 注入和中间件的 context 透传链条——这里断一环，整条链就只剩半截。
