traceid必须通过context.context显式透传，禁止全局变量或隐式状态；入口生成一次并注入私有key的ctx，日志写入前动态提取，goroutine、db、http/grpc调用均需显式传ctx，漏一处即断链。
Go日志中如何注入和传递TraceID
TraceID不能靠全局变量或context.Context以外的隐式状态传递，否则在goroutine切换、HTTP中间件、异步任务中必然丢失。最可靠的方式是把context.Context作为函数第一参数显式透传，并在日志写入前从ctx中提取traceID字段。
常见错误是直接在logrus/zap的WithField里硬编码一个随机ID，结果每个日志行ID都不一致，根本无法串联请求。正确做法是：所有入口（如HTTP handler）生成一次traceID，塞进context.WithValue，后续调用链中每一层都用ctx.Value("trace_id")取值，再注入日志实例。
- HTTP handler里用
uuid.New().String()生成traceID，存入ctx并传给下一层 - 日志封装函数（如
LogWithTrace）只负责从ctx读traceID，不负责生成 - 避免用
context.Background()启动新goroutine——必须用ctx派生子ctx，否则trace中断
为什么zap.Logger.With()不适合直接绑定TraceID
zap.Logger.With()返回新logger对象，看似方便，但容易误用成“一次赋值、全程复用”，导致多个请求共用同一个带traceID的logger，日志混杂。更危险的是，在goroutine里复用该logger时，traceID实际来自父goroutine，而非当前请求上下文。
真正安全的做法是每次日志写入前动态构造字段：用zap.String("trace_id", getTraceID(ctx))，而不是提前With(zap.String("trace_id", ...))。这样即使logger被多个goroutine共享，每条日志仍能拿到各自ctx里的正确ID。
- 不要在handler外层创建
logger.With(zap.String("trace_id", ...))然后传入业务函数 - 推荐封装一个
Log(ctx context.Context, msg string, fields ...zap.Field)函数，内部统一调用getTraceID(ctx) - 如果用了
zap.NewAtomicLevel()做日志级别热更新，更要避免提前绑定字段，否则level变更时可能漏掉trace上下文
HTTP中间件中TraceID的提取与透传要点
外部请求可能带X-Trace-ID头，也可能是空，这时要区分“继承”还是“新建”。直接覆盖或忽略都错：前者导致下游伪造trace，后者让跨服务调用断链。
标准逻辑是优先取header，为空则生成新ID；同时必须把traceID写回响应头X-Trace-ID，供下游服务继续使用。中间件里最容易踩的坑是没把新ctx传给next.ServeHTTP，导致后续handler拿到的是原始无trace的ctx。
- 用
r.Header.Get("X-Trace-ID")读头，非空且符合^[a-f0-9]{16,32}$格式才复用 - 用
context.WithValue(r.Context(), traceKey, traceID)生成新ctx - 调用
next.ServeHTTP(w, r.WithContext(newCtx))，不是r原样传入 - 别忘了
w.Header().Set("X-Trace-ID", traceID)，否则下游拿不到
异步任务（如go func）里TraceID为什么会丢失
goroutine启动时若没显式传入ctx，它就永远拿不到traceID。常见写法go doSomething()里doSomething函数没有ctx参数，自然无法获取上游trace。更隐蔽的问题是，有些库（如database/sql、redis-go）的回调函数不接受ctx，只能靠context-aware的客户端（如pgxpool、redis.UniversalClient.WithContext）来保trace。
- 所有
go func()必须显式接收并使用ctx参数，例如go func(ctx context.Context) { ... }(parentCtx) - 第三方SDK调用前，检查是否支持
WithContext(ctx)方法，不支持的要考虑换库或加wrapper - 定时任务（如
time.AfterFunc）同样需要捕获当前ctx，不能依赖闭包变量
db.Query没带ctx，或者gRPC client没用grpc.WithContext，整条链路就断在那一点。TraceID不是加个日志字段就完事，它是贯穿整个调用生命周期的上下文凭证。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
