http middleware 中应使用 uuid.newstring() 生成 traceid 并通过自定义 context key 存入 context，日志需自动提取 traceid，跨服务调用时通过 x-request-id header 透传。
HTTP middleware 里用 uuid.NewString() 生成 traceID 最直接
Go 的 HTTP handler 是无状态的，每次请求进来都是新实例，最适合在中间件里塞 traceID。用 uuid.NewString()（v1.20+）最省心，不用额外引入第三方 UUID 库，生成的字符串也符合常见日志和链路系统要求（32 位小写十六进制 + 连字符）。
常见错误是直接在 handler 外部定义全局变量 traceID，结果所有请求共享同一个 ID；或者用 time.Now().UnixNano() 拼接，高并发下容易重复。
- 必须在每个
http.Handler调用链开头生成，比如next.ServeHTTP(w, r)前 - 生成后要存进
context.Context，别只塞进map[string]string或自定义 struct——下游中间件或业务逻辑拿不到 - 别用
rand.Intn()加时间戳手搓，没经过 CSPRNG，有碰撞风险
用 context.WithValue() 传 traceID，但 key 类型不能是 string
Go 官方文档明确警告：用 string 当 context.Value 的 key 极易引发 key 冲突，尤其项目引入多个中间件或 SDK 时。你传的 "trace_id"，别人也可能传同名 key，值就被覆盖了。
正确做法是定义私有类型作 key：
type ctxKey string const traceIDKey ctxKey = "trace_id"
然后这样存取：
ctx := context.WithValue(r.Context(), traceIDKey, tid)
// ……
if tid, ok := ctx.Value(traceIDKey).(string); ok { /* 使用 */ }
- key 类型必须是未导出的自定义类型（如
ctxKey），不是string、int或公开 struct - 取值时务必做类型断言 +
ok判断，避免 panic - 别把 traceID 存进
http.Request.Header传下游服务——Header 是 HTTP 层概念，跨服务调用才需要，本机中间件间传递用 context 更轻量、更安全
日志打印时怎么自动带上 traceID？别手动拼接
手动在每条 log.Printf() 前加 [trace_id: %s] 不仅累，还容易漏。真正省事的是封装一个带 context 支持的日志函数，或用支持 context 的日志库（如 zerolog、zap）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
以 zerolog 为例，它原生支持从 context 提取字段：
logger := zerolog.New(os.Stdout).With().
Str("trace_id", getTraceIDFromCtx(r.Context())).
Logger()
但如果不想引入新库，最小改动是写个辅助函数：
func logRequest(ctx context.Context, msg string, args ...interface{}) {
if tid, ok := ctx.Value(traceIDKey).(string); ok {
log.Printf("[trace_id:%s] "+msg, append([]interface{}{tid}, args...)...)
} else {
log.Printf(msg, args...)
}
}
- 别依赖全局 logger 实例自动注入 traceID——除非你全程用同一 logger 实例且确保它被正确 wrap
- 如果用了
log/slog（Go 1.21+），可以用slog.With()+slog.Handler自定义，但注意slog默认不读 context，得自己实现Handler - 调试时临时打日志，用
fmt.Printf()看 traceID 是否存在，比翻日志更快
跨服务 HTTP 调用时，怎么把 traceID 透传给下游？
本服务生成的 traceID，要发请求给其他服务时，必须通过 HTTP Header 透传，否则链路就断了。OpenTelemetry 和大多数 APM 工具默认认 X-Request-ID 或 traceparent，但最通用、零配置兼容的是 X-Request-ID。
别只传一次就完事：下游返回 4xx/5xx 时，你重试的请求必须沿用原始 traceID，不能新生成一个。
- 用
req.Header.Set("X-Request-ID", tid)，不是Add()——避免重复 header - 如果下游是 Go 写的，且也按本文方式实现，它会自动从 Header 里提取并塞进自己的 context
- 调用 gRPC 服务？对应 Header 是
metadata.MD{"x-request-id": []string{tid}}，不是 HTTP Header 那套 - 注意反向代理（如 nginx）可能默认 strip 掉自定义 header，需显式配置
proxy_pass_request_headers on;
实际跑起来最常卡住的地方，是 traceID 在中间件里生成了、存进 context 了，但下游业务 handler 忘了从 r.Context() 里取，或者日志函数压根没接入 context —— 看似链路打通了，一查日志全是空 traceID。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
