字段隔离需强制注入tenant_id且全程不可绕过，schema隔离更安全但需为每个租户缓存独立*sql.db实例并设置search_path；gorm的count、preload等默认不感知租户，须显式传参或使用scopes(bytenant)。
字段隔离（tenant_id）够用，但必须从 DAO 层强制注入、全程不可绕过；schema 隔离更安全，PostgreSQL 下只需 SET search_path，可复用连接池——但别指望 GORM 自动帮你切 schema，得自己缓存租户专属 *sql.DB 实例。
为什么 tenant_id 字段隔离最容易出 P0 故障
不是它设计得不好，而是漏加一次 WHERE tenant_id = ? 就全完了。GORM 的 Count()、FirstOrInit()、Preload() 这些方法默认不感知租户上下文，db.Unscoped().Where("id = ?", 123).Find(&u) 更是直接绕过所有防护。
- 所有 DAO 函数签名必须显式带
tenantID string参数，禁止从context.Value里取——类型断言失败会 panic，异步任务里还可能丢失 - 禁用裸
db.Where().Find()调用；改用Scopes(ByTenant(tenantID))，把过滤逻辑收口到一个函数里 -
deleted_at软删除字段必须和tenant_id同级约束：不能只靠SoftDelete插件，得在 scope 里写Where("tenant_id = ? AND deleted_at IS NULL", tenantID) - 每张业务表的
tenant_id字段必须加联合索引，比如(tenant_id, email)或(tenant_id, created_at)，否则查询一慢就是秒级延迟
PostgreSQL schema 隔离怎么避免连接池失效
很多人试过 db.Exec("SET search_path TO tenant_abc")，结果发现下一次 db.Query 又回到 public ——因为连接被归还进池后，状态不保留。pgx 和 database/sql 都不保证同连接复用，所以不能靠“临时改 session 变量”来切 schema。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 正确做法是为每个租户维护独立的
*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 的钩子（如BeforeCreate）
GORM 中怎么让 Preload 也走租户隔离
Preload("Orders") 默认不会自动加 tenant_id 条件，哪怕主查询用了 ByTenant(tenantID)。GORM 不会把 scope 透传进关联查询，这是最常被忽略的越权点。
- 不要依赖全局
DefaultTableNameHandler改表名前缀（如tenant_abc_users），那会让迁移、测试、事务全部脱节 - 对每个关联模型，手动指定带租户 scope 的子查询：
Preload("Orders", ByTenant(tenantID)) - 如果用
Joins()，必须显式ON orders.tenant_id = users.tenant_id，不能只靠外键字段名匹配 - 启用
db.Session(&gorm.Session{PrepareStmt: true})可缓解预编译 SQL 复用导致的条件错乱，但不能替代显式传参
真正卡住多数团队的不是代码怎么写，而是租户生命周期操作——比如合并两个租户时，schema 隔离要导出再导入，字段隔离则要批量更新 tenant_id 并校验外键一致性。这些没法靠 ORM 自动完成，得自己写带事务回滚和断点续传的迁移工具，且必须在低峰期跑。没做过的人，往往低估了数据迁移的原子性难度。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
