go中traceid需手动绑定日志：http/rpc入口提取traceid并封装日志函数；zap需用otelzapcore+infoctx传ctx；中间件应从req.context()取span；goroutine必须传并控制ctx生命周期，避免traceid污染。
Go 中 traceID 和日志如何自动绑定
Go 标准日志本身不感知上下文，log.Printf 也不会自动读取 context.Context 里的 traceID。必须手动把 traceID 注入日志字段，或换用支持 context 的日志库。
最轻量的做法是：在 HTTP handler 或 RPC 入口处从 context.Context 提取 traceID（比如从 OpenTelemetry 的 trace.SpanFromContext），然后封装一个带字段的日志函数：
func logWithTrace(ctx context.Context, msg string, args ...interface{}) {
span := trace.SpanFromContext(ctx)
traceID := span.SpanContext().TraceID().String()
log.Printf("[traceID=%s] %s", traceID, fmt.Sprintf(msg, args...))
}
注意：span.SpanContext().TraceID().String() 返回的是 32 位十六进制字符串（如 4a7c5e2b1f9d0a8c3e4b5f6a7c8d9e0b），不是短 ID，别误用 span.SpanContext().TraceID().Bytes() 直接转字符串——会得到乱码。
用 zap + opentelemetry 实现结构化日志自动注入
zap 本身不自动读 context，但可通过 zapcore.Core 包装器 + context.WithValue 实现“日志写入时动态补字段”。关键点在于：不能只靠 context.WithValue 存 traceID，因为 zap 日志可能异步执行，而 context 可能已失效。
推荐做法是使用 opentelemetry-go-contrib/instrumentation/zap 提供的 OTELZapCore（需 v1.20+）：
- 它会在每次
Write时主动调用trace.SpanFromContext(ctx)，确保 traceID 来自当前实际执行日志的 goroutine 的 context - 要求日志调用必须显式传入 context，例如
logger.With(zap.String("user_id", "u123")).InfoCtx(ctx, "login success") - 若漏传
ctx（如用Info()而非InfoCtx()），traceID 字段为空，不会 panic
初始化示例：
import "go.opentelemetry.io/contrib/instrumentation/zap" core := zapcore.NewCore(encoder, sink, level) otelCore := zapot.NewCore(core, otelCore.WithTracerProvider(tp)) logger := zap.New(otelCore)
HTTP middleware 中如何透传并记录 traceID
OpenTelemetry 的 http.Handler 中间件（如 otelhttp.NewHandler）会自动从请求头（traceparent）解析 span 并注入 context，但默认不记录 traceID 到 access log。
要让 access log 包含 traceID，必须在中间件里显式提取并写入：
- 不要依赖
r.Header.Get("traceparent")手动解析——格式复杂且易出错；应从req.Context()获取 span - 避免在中间件里直接调用
log.Printf，否则无法与业务日志对齐格式；建议统一用 zap 的InfoCtx - 如果用了
gin或echo，需确认其 context 是否被 otelhttp 正确包装（gin 默认用gin.Context，需用gin.Context.Request.Context()拿到底层 context）
gin 示例：
router.Use(func(c *gin.Context) {
ctx := c.Request.Context()
span := trace.SpanFromContext(ctx)
if span.SpanContext().IsValid() {
c.Set("trace_id", span.SpanContext().TraceID().String())
}
c.Next()
})
后续日志可从 c.MustGet("trace_id") 读取，或更推荐直接传 c.Request.Context() 给 logger。
goroutine 泄漏导致 traceID 错乱的典型场景
Go 中常见错误：在 HTTP handler 里启动 goroutine 处理异步任务（如发消息、写 DB），但没把 context 传进去，或传了但没用 context.WithTimeout 控制生命周期。
后果是：该 goroutine 可能持续运行到下一个请求复用同一 goroutine 时，仍拿着旧的 traceID 写日志，造成日志污染。
- 正确做法：所有 goroutine 启动前，用
ctx = context.WithTimeout(parentCtx, 5*time.Second)包一层 - 禁止写
go doSomething()，必须写go doSomething(ctx)，并在函数内用select { case 响应取消 - 若用
worker pool模式，每个 worker 应从 channel 接收带 context 的 job，而非共享 handler 的原始 context
traceID 错乱很难 debug，因为它不报错，只让日志和链路图对不上——务必在压测或灰度期用随机采样检查日志中 traceID 的连续性和唯一性。
