log.Printf永不显示TraceID，因其完全不读context.Context，也不访问goroutine局部状态；必须封装日志函数或切换至zap/zerolog并配context wrapper才能自动注入。
GoLand调试时log.Printf为什么永远不显示TraceID
因为log.Printf完全不读context.Context，也不访问任何全局或goroutine局部状态。它就是纯函数式输出——你没手动拼，它就绝不会出现trace_id字段。
现象是：HTTP handler里用log.Printf("req start")没traceID，但同一请求里用zap.Logger.Info("req start")却有；这不是日志库“更高级”，而是log压根没设计上下文支持。
- 别指望给
log.SetPrefix加个[trace_id=...]——那是进程级前缀，所有goroutine共用，一并发就串 - 别在debug时临时改
log.Printf为fmt.Printf("[trace_id=%s] %s", getTraceID(ctx), msg)——ctx在log调用点可能已失效或未传入 - 真正能用的只有两种：封装自己的
Log函数（强制要求传ctx），或直接切换到zap/zerolog并配好context wrapper
调试阶段怎么快速验证TraceID是否透传成功
不是看日志有没有字段，而是看ctx.Value(traceIDKey)在关键位置是否非nil且值正确。最简验证法：
func handler(w http.ResponseWriter, r *http.Request) {
tid := r.Context().Value(traceIDKey)
log.Printf("DEBUG: trace_id = %+v", tid) // 这行必须先于任何业务日志
// ...
}
注意三点：
-
traceIDKey必须是自定义类型（如type ctxKey string），不能用"trace_id"字符串字面量，否则跨包取不到 - 如果打印出
<nil>，说明中间件没调用r.WithContext(newCtx)，或解析header失败后没fallback生成新ID - 如果打印出空字符串
""，说明header存在但解析逻辑漏了trim空格、大小写转换（如X-Request-ID误读成x-request-id）
GoLand里断点调试时TraceID突然消失的典型原因
不是GoLand的问题，是代码里隐式丢了ctx。最常踩的三个坑：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 启动goroutine时写
go func() { db.Query(...) }()——闭包捕获的是外层ctx变量，但新goroutine运行时外层函数可能已return，ctx被cancel或失效 - 调用第三方库（如
sqlx、ent）的异步方法时，没把带traceID的ctx传进去，比如db.QueryRow(ctx, ...)写成了db.QueryRow(context.Background(), ...) - 用了
logrus.WithField("trace_id", tid).Info(...)，但该logger实例在handler入口创建后被复用到多个goroutine，而tid是上一次请求的残留值
验证方式：在goroutine内部打个断点，执行ctx.Value(traceIDKey)看是否为nil。
为什么封装Logger比每次手动With更可靠
手动logger.With(zap.String("trace_id", tid)).Info(...)看似简单，但只要漏一次，链路就断在那一行。封装的核心是把“取值+注入”绑定在日志调用入口，而不是靠人眼检查。
一个最小可行封装：
func (l *TracedLogger) Info(ctx context.Context, msg string, fields ...zap.Field) {
if tid, ok := ctx.Value(traceIDKey).(string); ok {
fields = append(fields, zap.String("trace_id", tid))
}
l.logger.Info(msg, fields...)
}
这样调用时只需logger.Info(r.Context(), "db query")，无需重复提取和拼接。关键点：
- 不依赖初始化时绑定固定
trace_id字段——那只会是空值或旧值 - 不修改原
zap.Logger实例——避免并发写panic - 字段名统一用
trace_id（下划线），别混用traceId或TraceID，否则Loki/Grafana查不到
最易被忽略的是：封装后的Info方法必须在每个goroutine入口都显式传入当前ctx，而不是复用handler里构造的那个logger实例。
