RequestID全链路贯穿需在最外层中间件生成并注入，通过私有key存入context、写回响应头；goroutine须显式传ctx；DB/HTTP调用需带ctx；日志须实时从ctx取值；跨服务需透传X-Request-ID header。
RequestID 全链路贯穿不是加个中间件就完事——漏掉任意一个 goroutine、一次 DB 查询、一条日志，链路就断了。
Go HTTP 中间件里怎么安全注入 RequestID
必须在最外层中间件生成并注入，不能靠 handler 自己造，否则并发下 ID 可能复用或为空。关键动作有三步：读 header、校验并兜底、写回 context 和响应头。
- 优先读
X-Request-ID，但要用strings.TrimSpace()去空格，再用正则（如^[a-zA-Z0-9\-_]{8,64}$）校验格式；不合法就调用uuid.NewString()生成新 ID - key 必须是私有类型，比如
type requestIDKey struct{}，绝不能用"request_id"这种字符串字面量，否则第三方库可能冲突 - 务必调用
r = r.WithContext(context.WithValue(r.Context(), requestIDKey{}, id))，再传给next.ServeHTTP()；原*http.Request的 context 是只读的 - 别忘了写回响应头：
w.Header().Set("X-Request-ID", id)，否则网关或前端重试时无法串联
为什么 goroutine 里取不到 RequestID
Go 的 go func() {}() 不会自动继承父 goroutine 的 context，这是生产环境最常导致链路断裂的原因。
- 错误写法：
go doSomething()——doSomething函数内部调用req.Context().Value(...)拿到的是空 context - 正确写法：
go doSomething(ctx)，且函数签名必须显式接收ctx context.Context - 如果启动多个 goroutine，每个都得传入当前请求的
ctx，不能共用一个闭包变量 - 数据库查询必须用
db.QueryContext(ctx, ...)，HTTP 调用必须用client.Do(req.WithContext(ctx))，老版本sqlx默认不支持 context，得手动 wrap
日志怎么稳定带上 RequestID 而不漏不串
标准 log 包完全不感知 context，slog.Default() 和 zap.L() 也不会自动提取；字段值必须从当前 context 实时获取，不能缓存、不能拼接、不能写死。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 用
slog.With("request_id", ctx.Value(requestIDKey{}))创建新 logger，后续所有slog.Info都带字段；注意每次调用都要重新查ctx.Value，不能在初始化时缓存 - 用
zap时，推荐封装LoggerFromCtx(ctx context.Context) *zap.Logger，内部做类型断言：if id, ok := ctx.Value(requestIDKey{}).(string); ok { return zap.L().With(zap.String("request_id", id)) } - 避免在每条日志前手动加
zap.String("request_id", id)—— 易漏、难维护、高频日志下性能差 - 如果用了
gin，别依赖c.GetString("request_id")，它和c.Request.Context().Value(...)不一定同步；panic 场景下gin.Recovery()会重建 context，ID 必须在 Recovery 中间件之前注入
跨服务调用时 RequestID 怎么不丢
Go 的 http.Client 不会自动透传 X-Request-ID，gRPC 更要手动塞 metadata；下游服务是否识别该 header，决定了链路能不能续上。
- HTTP 调用：用
req.Header.Set("X-Request-ID", reqID)，别用Add，防止重复；若用retryablehttp等自动重试 client，需确保重试时复用原始 header，而非生成新 ID - gRPC 调用：用
metadata.Pairs("x-request-id", reqID)构造 metadata，并通过grpc.Header()或grpc.Trailer()透传 - 下游如果是 Python/Java 服务，确认它们是否解析
X-Request-ID（大小写敏感！），建议统一用小写 + 连字符命名 - OpenTelemetry 场景下，优先透传
traceparentheader，X-Request-ID仅作 fallback 或业务侧日志锚点，二者语义不同，别混用
真正难的不是生成 ID，而是让每个 goroutine、每次子调用、每条日志、每个出站请求，都带着它走完全程——只要有一个环节用错 key、忘传 ctx、误用全局 logger，链路就无声断裂，排查时根本看不出断在哪。
