Gin中间件不能通过c.GetHeader或c.Query获取租户ID——必须从JWT claims等可信源推导并绑定到context，用sync.Map缓存租户专属*sql.DB实例，显式传递使用，避免header/query伪造、连接泄漏及跨租户数据泄露。
直接结论：Gin 中间件不能靠 c.GetHeader("X-Tenant-ID") 或 c.Query("tenant_id") 提取租户标识来隔离数据源——这是 P0 级风险起点。 真正安全的做法是：从可信认证上下文（如 JWT claims）推导租户身份，再绑定到请求 context.Context，并用 sync.Map 缓存租户专属 *sql.DB 实例，后续所有 DB 操作必须显式使用该实例。
为什么 Gin 中间件里取 header/query 是危险的
前端可控字段（X-Tenant-ID、tenant_id query 参数）等于把租户边界交给了不可信输入。攻击者可伪造任意值，绕过网关鉴权后直接命中下游服务。真实故障案例中，curl -H "X-Tenant-ID: admin" http://api.example.com/users 就能读出其他租户全量用户列表。
- 网关层未校验或未注入租户上下文时，中间件拿到的 header 值毫无可信度
- Gin 的
c.Request.Context()默认不携带租户信息，c.GetHeader返回的是原始 HTTP 输入，不是认证结果 - 即使加了 RBAC，若 DAO 层仍依赖该 header 值拼 SQL 或选 DB，权限校验就形同虚设
租户 DB 实例必须用 sync.Map 缓存，不能每次请求 sql.Open
频繁调用 sql.Open 会导致连接泄漏、启动延迟、K8s 下 Pod 重启时连接池雪崩。PostgreSQL 默认最大连接数通常为 100，1000 个租户 × 每个默认 100 连接 = 直接 OOM。
- 缓存 key 推荐用子域名（如
acme.example.com → "acme"），比 UUID 更易排查、更贴近路由逻辑 - 每个租户
*sql.DB必须显式调用db.SetMaxOpenConns(5)和db.SetConnMaxLifetime(5 * time.Minute) - 初始化时执行
db.Exec("SET search_path TO tenant_" + tenantID)，之后所有Query/Exec自动落在对应 schema - 禁止手写表名拼接（如
"tenant_acme.users"），会破坏 GORM 钩子、事务和迁移一致性
Gin Handler 里怎么安全拿到并使用租户 DB
中间件验证通过后，应把租户专属 *sql.DB 注入 c.Request.Context()，Handler 内部统一从 ctx 取，而不是重复查缓存或重连。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 中间件中：
c.Request = c.Request.WithContext(context.WithValue(c.Request.Context(), dbKey, tenantDB)) - Handler 中：
tenantDB := c.MustGet(dbKey).(*sql.DB)—— 注意类型断言失败会 panic，建议封装成 safe helper - DAO 方法签名必须显式接收
tenantDB *sql.DB或tenantID string，禁止从 ctx.Value 动态取租户 ID 再查缓存（异步任务、定时器里 ctx 为空） - 别用
gorilla/mux的c.Set()，Gin 的c.Set()不跨中间件传递，且非线程安全
缓存键和 Redis 使用必须带 tenant_id
漏掉 tenant_id 是导致数据错乱的高频原因。多个租户查同名资源（如都叫 config），Redis 里存的就变成“谁先写谁赢”。
- 缓存 key 必须硬编码拼接，例如
"tenant:" + tenantID + ":config"或"tenant:" + tenantID + ":user:" + userID - 避免用 struct hash 或 JSON 序列化生成 key —— 字段顺序、tag 差异会导致键不一致
-
redis-go的Get返回nil时，必须把带tenantID的结果回填，否则下个租户会命中前一个租户的脏数据 - 日志、指标、错误上报也得带上
tenantID字段，否则排查时无法定位归属
最常被忽略的点是：GORM 的 Preload 和 Count 默认不继承租户上下文，哪怕主查询用了 WithTenant(tenantID)，关联查询仍可能查全库。解决方案不是加 Scope，而是让每个 DAO 方法自己控制关联表的 WHERE 条件——这要求租户 ID 必须是函数第一等参数，而非藏在 context 里。
