tenant_id字段隔离易出P0故障，因漏加WHERE tenant_id = ?即导致跨租户读写，GORM的Count、Preload等方法默认不感知租户，且Unscoped()可绕过所有防护；必须DAO层显式传tenantID、禁用裸Where、用Scopes收口、软删除与tenant_id同级约束、建联合索引，并为PostgreSQL schema隔离缓存租户专属*sql.DB实例、设search_path及连接池限流。
tenant_id字段隔离为什么容易出P0故障
漏加一次WHERE tenant_id = ?就直接跨租户读写，GORM的Count()、Preload()、FirstOrInit()默认都不带租户上下文，连db.Unscoped().Where("id = ?", 123).Find(&u)都能绕过所有防护。
- DAO层所有方法签名必须显式接收
tenantID string参数，禁止从context.Value()取——类型断言失败会panic，异步任务里还可能丢失 - 禁用裸
db.Where().Find()调用，统一用Scopes(ByTenant(tenantID))收口过滤逻辑 -
deleted_at软删除必须和tenant_id同级约束：Where("tenant_id = ? AND deleted_at IS NULL", tenantID)，否则Unscoped()一调就全暴露 - 每张表的
tenant_id字段必须建联合索引，比如(tenant_id, email)或(tenant_id, created_at)，不然分页查慢成秒级延迟
PostgreSQL schema隔离怎么避免连接池失效
SET search_path TO tenant_abc是session级命令，但*sql.DB连接池不保证复用同一物理连接。执行完归还，下次取到的连接仍是public schema——这是最常被忽略的失效点。
- 不能靠中间件里动态
Exec("SET search_path")，得为每个租户缓存独立*sql.DB实例，用sync.Map存tenantID → *sql.DB - 首次初始化时，用标准DSN打开连接，立刻执行
db.Exec("SET search_path TO " + schemaName)，后续所有操作自动落在该schema - 必须调
db.SetMaxOpenConns(5)和db.SetConnMaxLifetime(5 * time.Minute)，否则1000个租户 × 默认100连接 = 直接打崩PostgreSQL - 别手写
"tenant_abc.users"拼表名——破坏ORM抽象、难测、无法用GORM钩子，search_path才是轻量且兼容所有驱动的方式
租户标识怎么从HTTP请求里安全提取
靠X-Tenant-ID header是最危险的起点，等于把租户边界交给不可信输入。真正能信任的只有登录态中已验证的归属关系。
- 子域名（如
acme.example.com）是最常用且运维友好的方式：用net.SplitHostPort(r.Host)先剥离端口，再strings.SplitN(host, ".", 2)切分，主域名必须定义为常量，不能硬编码 - JWT payload里存
tenant_id和tenant_role，签名校验通过才解出；别在middleware里重新解析或转换 - 提取后用
c.Set("tenant_id", tid)注入Gin context，后续handler全部从c.MustGet("tenant_id")取，别从query/header二次读取 - 本地开发时
localhost或127.0.0.1应跳过租户提取，或配置白名单，防止测试失败
缓存键和Casbin策略为什么必须带tenant前缀
缓存键漏掉tenant_id是数据错乱的高频原因，Casbin默认RBAC模型在多租户下会越权——这两处不显式绑定租户，其他层做得再严也白搭。
立即学习“go语言免费学习笔记（深入）”；
- Redis key必须形如
tenant:abc123:user:123或tenant:abc123:feature_flag:paywall，硬编码拼接比struct hash更可控 - Casbin必须改四元组模型：
r = sub, tenant, obj, act，并在[matchers]里强制校验r.tenant == p.tenant - 调用时传四参数：
e.Enforce("alice", "tenant-abc", "/api/users", "read")，策略行也要显式带租户：p, admin, tenant-abc, /api/users, read - 别为每个租户启一个Enforcer实例——内存爆炸；用单实例 + 四元组 +
FilteredAdapter加载租户策略子集更可控
真正难的不是写tenant_id字段或SET search_path，而是让每个DAO调用、每次缓存操作、每条权限规则都刚性绑定租户上下文——少一处，就少一道防线。
