traceid必须在http入口中间件生成并注入context.context：优先从x-trace-id或traceparent头提取，未命中则用uuid.newstring()生成；key须为私有类型（如type traceidkey struct{}），通过r.withcontext(context.withvalue(r.context(), traceidkey{}, traceid))更新请求上下文，并写回响应头；日志需基于该traceid构建带字段的logger实例并存入context，下游http调用须通过roundtripper或otelhttp自动透传，goroutine启动必须显式传递已注入traceid的ctx。
TraceID 必须在请求入口生成并注入 context.Context，后续所有中间件、业务逻辑、下游调用都依赖这个上下文传递——漏掉任意一环，链路就断了。
HTTP 中间件里怎么安全生成和注入 TraceID
入口中间件是唯一可信的 TraceID 源头，不能靠 handler 里临时生成，也不能复用 http.Request 的原始 Context 就完事。
- 优先从
r.Header.Get("X-Trace-ID")或r.Header.Get("traceparent")提取，有则直接复用；没提取到才用uuid.NewString()生成（Go 1.20+ 原生支持，无需额外依赖） -
key必须是私有类型，比如type traceIDKey struct{}，绝不能用字符串"trace_id"—— 多个中间件或 SDK 同时写会覆盖 - 注入后要更新
*http.Request：r = r.WithContext(context.WithValue(r.Context(), traceIDKey{}, traceID))，否则下游拿不到 - 别忘了把 TraceID 写回响应头：
w.Header().Set("X-Trace-ID", traceID)，方便前端或网关追踪
日志怎么自动带上 TraceID 而不每行手动加
zap 或 logrus 不会自己从 context.Context 读值，靠 log.Info("msg", zap.String("trace_id", id)) 这种写法既重复又容易漏。
- 在中间件中拿到
traceID后，立刻构建一个带字段的 logger 实例：logger := zap.L().With(zap.String("trace_id", traceID)) - 把这个
logger通过context.WithValue存进 context（用另一个 key，比如loggerKey{}），后续 handler 取出来直接用 - 如果用的是 gin，确保 trace 中间件在 logger 中间件之前执行；gorilla/mux 则必须在
http.Handler包裹层就完成WithValue注入
下游 HTTP 调用时怎么透传 TraceID 不出错
Go 的 http.Client 不会自动读 context 里的值，也不会自动塞 header，全靠你显式处理。
- 别在每个
http.NewRequest里手写req.Header.Set("X-Trace-ID", ...)—— 容易漏、难维护 - 封装一个带 context 传播能力的
http.RoundTripper：在RoundTrip方法里从req.Context()取traceID，再写入 header - 或者直接用
otelhttp.NewClient(http.DefaultClient)，它自动处理traceparent格式注入（前提是已初始化 OpenTelemetry 全局 propagator） - 注意：如果服务同时走 HTTP 和 gRPC，建议统一用小写
"trace-id"作 key，避免大小写歧义（HTTP header 不区分大小写，metadata key 区分）
最常被忽略的一点：新开 goroutine 时，go fn(r.Context()) 是无效的——子 goroutine 拿不到你注入的 TraceID。必须写成 go fn(ctx)，其中 ctx 是已经 WithValue 过的那个。跨 goroutine 传播不是自动的，得手动带过去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
