字段隔离易出P0故障，因漏加WHERE tenant_id = ?即导致全量数据泄露：GORM的Preload、Count、Unscoped等操作天然绕过Scopes，软删除未与tenant_id同级约束时可被直接绕过，DAO层必须显式传tenantID且禁用裸查询。
字段隔离（tenant_id）为什么容易出 P0 故障
不是因为写法难，而是漏加 WHERE tenant_id = ? 的成本太高——GORM 的 Preload、Count、FirstOrInit、甚至 Unscoped() 都不继承租户条件，一次调用就跨租户读全量数据。更危险的是软删除字段 deleted_at 若没和 tenant_id 同级约束，Unscoped().Where("status = ?", "active") 会直接绕过租户边界。
- 所有 DAO 方法签名必须显式接收
tenantID string，禁止裸调db.Where().Find() - 用 GORM
Scopes封装tenantScope，但需确认它能透传到关联查询和聚合操作中（v2 默认不透传） -
tenant_id字段必须加联合索引，例如(tenant_id, created_at)，否则分页查询延迟飙升 - 缓存 key 必须硬编码拼接
tenant:{tenant_id}:user:{id}，不能靠 struct hash 或忽略租户维度
Schema 隔离在 PostgreSQL 中怎么避免连接池失效
SET search_path TO tenant_abc 是 session 级命令，但 *sql.DB 连接池不保证复用同一物理连接——上一个请求执行完就归还，下一个请求取到的连接仍是默认 public schema。这不是配置问题，是连接池抽象层的固有行为。
- 必须为每个租户缓存独立的
*sql.DB实例，用sync.Map存tenant_id → *sql.DB - 初始化时 DSN 拼接
options=-c+search_path=tenant_abc，而非运行时执行SET（GORM Session 不支持动态换 schema） - 迁移工具（如
golang-migrate）无法动态切换 schema，得遍历租户列表逐个执行migrate.Up - 别用全局变量或 context 透传租户 ID 再手动拼表名（如
tenant_abc.users），破坏 ORM 抽象且难测
HTTP 请求里 tenant_id 从哪来才可信
靠前端传 X-Tenant-ID 或 URL 参数等于把租户边界交给不可信输入。真正可信的只有登录态中已验证的归属关系——JWT payload 解析后带出的 tenant_id 和 tenant_role，且签名校验必须通过。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 中间件提取租户标识时，必须用私有未导出类型作 context key（如
type tenantKey struct{}），避免 key 冲突 - 子域名（如
acme.example.com）比 header 更可靠，解析时要用net.SplitHostPort(r.Host)先剥离端口，再切分 - 本地开发时
localhost应跳过租户提取，或配置白名单，防止测试链路中断 - 绝不在 DAO 层用
context.Value()拼 SQL，那等同于手写 SQL 注入；Context 只负责透传，隔离逻辑在查询构造或连接路由层
Redis 缓存键漏 tenant_id 是设计缺陷，不是并发问题
多个租户查同一资源名（比如都叫 config），Redis 里存的就变成“谁先写谁赢”。这不是缓存击穿或竞争条件，是 key 设计缺失租户维度导致的脏数据污染。
立即学习“go语言免费学习笔记（深入）”；
- 所有缓存 key 必须显式包含
tenant:{tenant_id}前缀，格式统一为tenant:{tenant_id}:feature_flag:paywall - 缓存 miss 后查 DB，必须把带
tenant_id的结果回填，否则下个租户直接命中前一个租户的旧值 - 用闭包封装租户安全的缓存操作：如
makeTenantCacheWriter("t123", redisClient)返回的函数自动拼前缀，调用方无需感知租户 - groupcache 或 ristretto 这类本地缓存也需同样处理，租户维度不能只靠 Redis 层兜底
tenant_id 并重建索引。这些路径必须在架构初期就定义清楚，不能等线上出事才补。 
