Go HTTP中间件应在请求入口统一生成traceID并注入context，通过私有key避免冲突；日志需由支持context的handler自动提取traceID，而非手动添加或依赖全局变量。
Go HTTP 中间件怎么注入 traceID 到 context
日志里要关联 traceID，前提是请求生命周期内能稳定拿到它——最直接的方式是在接收请求时生成 traceID，并塞进 context.Context，后续所有日志、下游调用都从这个 context 里取。
别在 handler 里手动生成再传参，容易漏；也别用全局变量或 goroutine-local，Go 的并发模型下不安全。
- 用
middleware包裹所有 HTTP handler，在入口统一生成traceID（比如用uuid.NewString()或google.golang.org/x/exp/rand生成短 ID） - 通过
context.WithValue(r.Context(), traceKey, traceID)注入，traceKey必须是私有类型（不能是string），避免 key 冲突 - 如果用了 OpenTelemetry，优先走
otel.GetTextMapPropagator().Extract()尝试从headers（如traceparent）中提取已有 traceID，没有再新建
log/slog 怎么自动读取 context 中的 traceID
slog 本身不感知 context，但可以靠 slog.Handler 实现自动注入。自己写个 wrapper handler，在 Handle() 方法里尝试从 context.Context 取 traceID，再合并进日志属性里。
别依赖 logger 实例带 context，那是错觉；也别每个 slog.Info() 都手动加 slog.String("trace_id", ...)，维护成本高还容易漏。
立即学习“go语言免费学习笔记（深入）”；
- 实现一个
contextAwareHandler，嵌套原始 handler（如slog.JSONHandler） - 在
Handle(ctx context.Context, r slog.Record)中调用ctx.Value(traceKey)，若存在则用r.AddAttrs(slog.String("trace_id", id)) - 确保你用的是
slog.With().Info()或显式传入带 traceID 的 context，否则Handle()收不到 context（slog 默认不透传）
为什么 zap.Logger.WithOptions(zap.AddCaller()) 会丢 traceID
zap 的 WithOptions 是配置级操作，只影响 logger 初始化行为，不会把 context 数据自动挂到每条日志上。加了 zap.AddCaller() 只是多打文件行号，和 traceID 完全无关。
常见错误是以为 “加个 option 就能自动带上下文”，结果日志里 traceID 全是空，查链路时断成一截一截的。
- zap 没有内置 context 绑定机制，必须手动用
logger.With(zap.String("trace_id", id))构建子 logger - 更稳妥的做法：封装一个
WithContext(ctx context.Context) *zap.Logger方法，内部提取 traceID 后调用With() - 注意子 logger 是无状态的，每次都要重新 With，不能复用一个“带 traceID 的 logger”处理多个请求
gin 框架里 logrus 怎么避免重复打印 traceID
gin 自带的 gin.Logger() 中间件和你自己写的日志逻辑常同时触发，导致同一请求出现两条日志，其中一条没 traceID，另一条有——看起来像“有时有有时没有”，其实是日志来源混了。
根本问题不是 traceID 生成失败，而是日志出口没对齐。
- 禁用 gin 默认 logger：
gin.SetMode(gin.ReleaseMode)并移除gin.Logger()中间件 - 所有日志统一走你封装的
logrus.Entry，该 entry 已通过 middleware 注入 traceID（如entry.WithContext(c.Request.Context())） - 如果要用
logrus.WithContext()，确保你在中间件里已调用c.Request = c.Request.WithContext(...)，否则logrus.WithContext()拿不到东西
traceID 要贯穿整个请求链路，关键不在“怎么打”，而在“谁负责注入、谁负责读取、谁负责传递”。漏掉任意一环，比如 downstream HTTP client 没把 traceID 写进 header，或者数据库查询日志没接上 context，整条链就断了。这种问题往往线上跑几天才暴露，排查时得顺着调用栈逐层确认上下文是否被正确携带和消费。
