go中需在请求入口生成traceid并透传至context，用fmt.errorf("%w")包装错误保留链路，日志时从context提取traceid显式传入（如zap.string("trace_id", tid)），禁用全局变量或修改error.error()。
Go 错误日志里怎么塞进 TraceID
TraceID 必须在请求入口就生成并透传，不能等报错时再临时加。Go 的 error 类型本身不带上下文，直接用 fmt.Errorf 或 errors.New 会丢掉 TraceID；得靠包装（wrap）机制把上下文信息附着到 error 上。
- 推荐用
fmt.Errorf("xxx: %w", err)包装原始错误，保留栈和因果链 - 在中间件或 handler 入口从 context 提取 TraceID（比如从 HTTP Header 的
X-Trace-ID或自动生成），存入context.Context - 日志打印前，从当前
context取出 TraceID，和err.Error()拼一起——别试图改写 error 的Error()方法，容易破坏标准行为 - 如果用了
zap或zerolog，直接在logger.With().Error()里传trace_id字段，比塞进 error 字符串更干净
用 context.WithValue 传 TraceID 安全吗
安全，但必须配对使用且类型严格。Go 官方明确说 context.WithValue 是“最后的选择”，但它确实是跨函数传 TraceID 最轻量、最通用的方式。
- 键不能用字符串字面量（如
"trace_id"），得定义为私有类型避免冲突：type traceIDKey struct{}，然后用context.WithValue(ctx, traceIDKey{}, "abc123") - 取值时务必做非空和类型断言：
if tid, ok := ctx.Value(traceIDKey{}).(string); ok { ... } - 不要把 TraceID 存进全局变量或 struct 字段——并发下会串，context 才是 Go 的标准传递通道
- 注意：HTTP 中间件里若用了
http.Request.Context()，它本身已带 cancel 和 deadline，WithValue不影响这些语义
log.Printf 和 zap.Error 为什么都打不出 TraceID
因为它们根本不读 context。日志库只处理你传进去的参数，不会自动扒拉当前 goroutine 的 context 里的东西。
-
log.Printf("failed: %v", err)—— 这行永远看不到 TraceID，除非你手动拼：log.Printf("[trace_id=%s] failed: %v", getTraceID(ctx), err) -
logger.Error("db query failed", zap.Error(err))—— 同样没 TraceID，得显式加字段：zap.String("trace_id", getTraceID(ctx)) - 常见坑：在 defer 函数里打日志，但 defer 执行时 context 可能已被 cancel 或覆盖，TraceID 取出来是空或旧值
- 建议封装一个带 TraceID 的日志辅助函数，比如
LogError(ctx, "msg", err)，内部统一取值+打点
第三方 error 库（如 pkg/errors）还值得用吗
不推荐新项目引入 pkg/errors，它已被 Go 1.13+ 原生 %w 语法替代。但要注意：原生 error wrap 不携带任何字段，TraceID 仍需靠 context 或日志层补全。
立即学习“go语言免费学习笔记（深入）”；
-
errors.Is和errors.As能正常穿透%w包装的 error，不影响错误分类逻辑 - 别用
pkg/errors.WithStack或github.com/go-errors/errors——它们额外增加栈捕获开销，且和标准库 error 接口不完全兼容 - 如果真需要结构化 error（比如带 code、status、trace_id 字段），不如定义自己的 error 类型实现
error接口，但仅限关键业务错误，别泛滥 - 记住：TraceID 是请求维度的元信息，不是错误本身的属性；混在一起反而模糊职责
真正难的不是加 TraceID，而是保证它从入口到每一层 goroutine、每一个子 context、每一次日志输出都不丢失——漏掉任意一环，链路就断了。
