Zap 默认不带 TraceID是因为其本身无上下文感知能力，不持有或自动提取context.Context中的值；必须手动从ctx中安全提取trace_id并作为zap.Field显式传入日志，否则直接调用ctx.Value会因ctx为nil而panic。
为什么 Zap 默认不带 TraceID，硬塞 context 字段会崩
Zap 本身是无上下文感知的日志库，zap.Logger 实例不持有 context.Context，所以直接在日志里写 ctx.Value("trace_id") 是错的——运行时可能 panic，因为 ctx 可能为 nil，且 Zap 不负责透传或提取它。
真正可行的路径只有一条：把 TraceID 提前从 context 里抽出来，作为 zap.Field 显式传入每条日志。
如何用 zap.String("trace_id", ...) 安全注入 TraceID
关键不是“怎么加字段”，而是“在哪取、何时取、取错了怎么办”。常见错误是：在中间件里取一次 TraceID 就缓存到全局变量，结果并发请求互相覆盖。
- 每次进 handler 或业务入口，从
context中提取 TraceID（例如从 gRPC metadata 或 HTTP header 的X-Trace-ID） - 用
ctx = context.WithValue(ctx, keyTraceID, traceID)把它塞回上下文（仅作传递，Zap 不读它） - 调用日志时统一用
logger.With(zap.String("trace_id", traceID))构建子 logger，后续所有.Info()/.Error()都自动携带该字段 - 如果 TraceID 为空（比如测试环境没传），建议 fallback 到
uuid.New().String()，避免字段缺失导致日志查询断链
zap.Logger 子 logger 的生命周期和内存开销要注意什么
频繁调用 logger.With(...) 不会泄漏内存，但滥用会导致字段堆叠：比如在 for 循环里反复 With(zap.String("attempt", strconv.Itoa(i)))，最后一条日志可能带上几十个冗余字段。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 子 logger 应该绑定到一次请求生命周期，而不是每个函数调用都 new 一个
- 推荐模式：
reqLogger := logger.With(zap.String("trace_id", tid), zap.String("method", r.Method))，然后整个 handler 内复用reqLogger - 不要用
logger.With(...).With(...).With(...)链式调用嵌套，可读性差且易漏字段；拆成单次With传多个zap.Field - 字段名统一用小写字母+下划线（如
"trace_id"），避免和 OpenTelemetry 标准字段冲突
Go 语言学习阶段最容易忽略的 TraceID 观测陷阱
初学时容易把“能打印 TraceID”当成“已实现可观测”，其实真正的断点在：日志是否和 span、metric 对齐？有没有跨 goroutine 丢失？
立即学习“go语言免费学习笔记（深入）”；
- goroutine 启动时没传递 context（比如
go fn()而非go fn(ctx)），TraceID 就断了——必须显式传参并重新提取 - 用
log.Printf或第三方库（如 sqlx、redis-go）内部日志，不会自动继承你的trace_id字段，得靠 hook 或 wrapper 重定向 - 本地开发时关掉采样（
sampled: false），但忘了上线后没开，结果日志有 TraceID，APM 系统却收不到对应 span，查链路时以为“日志丢了”，其实是 span 没上报 - Zap 字段顺序不保证，别依赖
trace_id总在第一行；用结构化日志解析器（如 Loki 的 LogQL、ES 的 grok）按字段名提取，而非正则匹配位置
