gin 的 *gin.context 不能跨服务传递，因其生命周期仅限单次请求；跨服务需通过 http header 透传 trace_id 等字段，并在下游用中间件注入到 c.request.context() 中，再由 http.newrequestwithcontext() 自动携带。
为什么 Gin 的 *gin.Context 不能直接跨服务传递
HTTP 请求生命周期只存在于单次调用中，*gin.Context 是 Gin 在每次请求进入时创建的内存对象，它不跨网络、不跨进程、也不跨服务。你在 A 服务里用 c.Set("trace_id", "abc123") 存的数据，到 B 服务的 *gin.Context 里根本不存在——B 服务收到的是全新的 HTTP 请求，它的 *gin.Context 是从头构建的。
所谓“上下文传递”，本质是把关键字段（如 trace_id、user_id、tenant_id）从上游服务通过 HTTP Header 或 Query 参数带过来，下游服务再手动提取、校验、注入到自己的上下文里。中间件只是帮你自动化这个提取和注入过程。
TraceID 和 UserID 的透传中间件怎么写
典型做法是定义一个中间件，从 X-Request-ID、X-User-ID 等标准 Header 中读取值，并存入 c.Request.Context()（注意：不是 c.Set()），这样后续业务逻辑或下游 HTTP 客户端都能复用。
- 必须用
c.Request = c.Request.WithContext(...)更新原生*http.Request的 context，否则context.WithValue的数据无法被http.Client自动带上 - Header 名称要统一，推荐用
X-Request-ID（OpenTracing 兼容）、X-User-ID、X-Tenant-ID - 对空值或非法格式要做降级处理，比如
X-User-ID缺失时设为"anonymous"，而不是直接c.Abort() - 不要在中间件里做鉴权校验——那是认证中间件的事；透传中间件只负责“搬运”和“标准化”
func ContextPropagation() gin.HandlerFunc {
return func(c *gin.Context) {
req := c.Request
ctx := req.Context()
if traceID := c.GetHeader("X-Request-ID"); traceID != "" {
ctx = context.WithValue(ctx, "trace_id", traceID)
}
if userID := c.GetHeader("X-User-ID"); userID != "" {
ctx = context.WithValue(ctx, "user_id", userID)
}
c.Request = req.WithContext(ctx)
c.Next()
}
}
下游调用时如何自动带上这些上下文字段
单纯在 *gin.Context 里存了值没用，关键是要让你的 HTTP 客户端（比如 http.DefaultClient 或自定义的 *http.Client）在发起请求时，把 context 里的值写进 outbound 请求头。
- 必须用
http.NewRequestWithContext(c.Request.Context(), ...)构造请求，不能用http.NewRequest() - 自己封装一个通用的
DoWithCtx函数，在发送前从c.Request.Context()里读取trace_id、user_id并写入req.Header - 避免硬编码 Header 名：建议把透传字段名定义为常量，上下游保持一致，比如
const TraceIDKey = "trace_id" - 如果用了
gorilla/handlers.CORS或其他第三方中间件，确认它们不会覆盖或清除你设置的 Header
容易被忽略的边界问题
最常踩的坑不是代码写错，而是部署和链路配合没对齐：
- 网关层（如 Nginx、API Gateway）必须透传相关 Header，否则第一跳就断了；检查
proxy_pass_request_headers on和proxy_set_header X-Request-ID $request_id - Kubernetes Ingress 默认会 strip 掉非标准 Header，需显式配置
nginx.ingress.kubernetes.io/enable-cors: "true"并加白名单 - Go 的
http.Client对 Header 名大小写敏感，X-Request-Id和X-Request-ID是两个不同 Header - 日志打点时如果只依赖
c.GetString("trace_id")，但你中间件写的是c.Request.Context()，那日志里永远为空——务必统一使用c.Request.Context().Value("trace_id")
跨服务上下文不是靠 Gin 自身能力实现的，而是靠约定 + 中间件 + 客户端协作完成的一条链。漏掉任意一环，trace 就断在某个服务里，查问题时连日志都串不起来。
