租户上下文应由入口层（如网关）解析X-Tenant-ID请求头并校验后，通过context.WithValue()注入，使用私有key只存租户ID；RBAC策略分层加载，权限检查函数自动从ctx提取租户ID查缓存；数据访问层强制tenantID参数与SQL注入约束；JWT仅用于身份认证，不承载租户授权信息。
租户上下文怎么安全透传到每个 Handler
Go HTTP 服务里，context.Context 是唯一靠谱的租户信息载体，但直接往 req.Context() 塞租户 ID 或角色列表，容易被中间件覆盖或漏传。关键不是“能不能传”，而是“谁负责注入、谁有权读取、谁不能篡改”。
- 入口层（如网关或反向代理）必须通过请求头（如
X-Tenant-ID）解析并校验租户合法性，再调用context.WithValue()注入，**绝不允许业务 Handler 自己从 header 解析** - 所有中间件和 Handler 必须使用自定义 key（比如
tenantCtxKey类型的私有 struct），避免和标准库或其他模块 key 冲突 - 不要把完整
*Tenant结构体塞进 context —— 只存 ID，需要时再查缓存；否则 context 生命周期过长易引发内存泄漏 - gRPC 场景同理，但要用
metadata.MD提取，再转成 context value，且需在 server interceptor 统一做
RBAC 规则怎么和租户维度解耦又不牺牲性能
硬编码 map[string]map[string][]string 存租户+角色+权限，上线后改一条规则就得重启，也不支持动态授权。真正可行的是分层加载：租户级策略存数据库（带 TTL 缓存），全局默认策略走代码常量。
- 权限检查函数签名建议为
Can(ctx context.Context, action string, resource string) bool，内部自动从 ctx 提取租户 ID 并查缓存 - 缓存 key 必须包含租户 ID + 规则版本号（如 etag 或更新时间戳），避免租户间规则互相污染
- 不要在每次 HTTP 请求里查 DB —— 即使用了 Redis，也得加一层本地 LRU（如
groupcache或fastcache），否则高并发下 Redis 成瓶颈 - 资源标识（如
user:123）需标准化，避免user/123和/api/v1/users/123被当成不同资源
多租户数据隔离最容易被绕过的三个点
光靠 WHERE tenant_id = ? 不够，尤其当 ORM 自动生成 SQL 或用 Raw Query 拼接时，很容易漏掉租户条件。真正的隔离必须在数据访问层强制约束，而不是靠开发自觉。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有 DAO 方法必须显式接收
tenantID string参数，禁止提供无租户参数的 FindAll()、DeleteAll() 等“便利方法” - 用
sqlx.Named或 GORM 的 Scopes 强制注入tenant_id = :tenant_id，而不是拼字符串 —— 否则 SQL 注入可能绕过租户过滤 - 数据库连接池要按租户分组？别折腾。更稳的做法是统一连接池 + 全局租户字段 + DDL 层面加 CHECK 约束（如
CHECK (tenant_id = current_setting('app.tenant_id'))，配合 PostgreSQL row-level security）
为什么 JWT 不能直接当租户凭证用
JWT 里塞 tenant_id 字段看似简单，但一旦签发就无法主动失效，租户停用或角色变更后，token 还能继续访问，这是生产事故高发区。
立即学习“go语言免费学习笔记（深入）”；
- JWT 只用来做身份认证（AuthN），不做租户授权（AuthZ）—— 验证通过后，立刻用其中的用户 ID 查数据库拿到当前租户上下文
- 不要把租户 ID 放在 JWT payload 里长期缓存；如果非要放，必须设极短有效期（如 5 分钟），并配合 Redis 黑名单做实时吊销
- 前端传来的 JWT 必须验证
iss和aud，防止攻击者伪造其他租户的 token（比如把aud改成另一个租户名）
租户隔离最麻烦的从来不是技术选型，而是边界模糊：一个日志埋点该记哪个租户？一个异步任务失败后重试，上下文里的租户信息还在不在？这些地方没想清楚，再漂亮的 RBAC 设计也会漏。
