gin中间件拿不到原始租户header，主因是上游未透传或反向代理（如nginx/kong）截断/重写；需先用log打印c.request.header确认是否抵达go进程，再按header→query→context优先级提取并校验后存入c.set("tenant_id", tid)。
为什么 Gin 中间件里拿不到原始租户 header
因为微服务调用链中，上游服务可能没传 X-Tenant-ID，也可能传了但被反向代理（如 Nginx）或网关（如 Kong、API7）截断或重写。Gin 默认不自动透传非标准 header，c.Request.Header.Get("X-Tenant-ID") 返回空字符串不等于“没传”，更可能是 header 在到达 Gin 前就被过滤了。检查时先确认请求进到 Go 进程前是否还在：在中间件开头加 log.Printf("headers: %+v", c.Request.Header)，看输出里有没有 X-Tenant-ID。
如何在 Gin 中间件中安全提取并透传租户标识
提取逻辑要兼顾容错和来源优先级：优先取 header，fallback 到 query 或 context value（用于内部 RPC 透传），禁止从 cookie 或 body 解析（易被篡改）。透传则必须确保下游调用（如 http.Client 发起的请求）带上该标识。关键点：
- 用
c.Request.Header.Get("X-Tenant-ID")提取，不是c.GetHeader()（后者是别名，没问题，但显式写全更清晰） - 校验值是否为空、是否含非法字符（如控制符、空格），建议用正则
^[a-zA-Z0-9_-]{3,32}$ - 校验通过后，存入 Gin 的
c.Set("tenant_id", tenantID)，供后续 handler 使用 - 若需透传给下游 HTTP 服务，在调用前设置
req.Header.Set("X-Tenant-ID", tenantID)，且确保req.Header是新构造的 *http.Request 实例的 header，不是复用旧请求的引用
跨服务调用时租户 ID 丢失的典型场景与修复
最常见的是 Go 的 http.Client 默认不继承父请求 header，尤其当用 http.NewRequestWithContext() 但没手动 copy header 时。另一个坑是使用第三方 HTTP 客户端（如 resty）时，没调用 .SetHeaders() 或漏了 X-Tenant-ID。修复方式：
- 统一封装一个
DoWithTenant(ctx context.Context, req *http.Request, tenantID string) (*http.Response, error)函数，在里面做req.Header.Set("X-Tenant-ID", tenantID) - 若用 resty，初始化 client 后加
client.SetHeader("X-Tenant-ID", tenantID)不行——那是默认 header，每次请求仍需显式 set；正确做法是在每个client.R()后调用.SetHeader("X-Tenant-ID", tenantID) - 注意 gRPC 场景：租户 ID 要塞进
metadata.MD，用metadata.AppendToOutgoingContext(ctx, "tenant-id", tenantID)，下游用metadata.FromIncomingContext()取
中间件注册顺序对租户透传的影响
Gin 中间件执行顺序直接影响租户 ID 是否能被后续中间件或 handler 拿到。如果自定义的日志中间件在租户中间件之前注册，它就看不到 tenant_id；如果 JWT 鉴权中间件在租户中间件之后，它可能无法基于租户做策略路由。务必保证：
- 租户中间件注册在所有依赖租户信息的中间件之前
- 若同时有鉴权中间件（如检查 token scope 是否匹配租户），它应放在租户中间件之后、业务 handler 之前
- 不要把租户中间件和 CORS 中间件混用——CORS 的
Access-Control-Allow-Headers必须显式包含X-Tenant-ID，否则浏览器预检失败
租户标识本身不加密，也不应作为权限判断唯一依据；它的作用只是上下文隔离和日志归因，真正的权限控制还得走 RBAC 或 ABAC 策略引擎。这点容易被忽略，结果线上出问题才想起来租户 ID 被恶意伪造了。
