PostgreSQL schema隔离是Go多租户架构中真正可落地、可运维的默认方案，字段级隔离（tenant_id）仅适用于中小SaaS、验证期或租户数少于50且无安全审计要求的场景。
PostgreSQL schema 隔离是 Go 多租户架构中真正能兜底的方案，字段级隔离（tenant_id）只适合验证期或租户数 WHERE tenant_id = ?，就是 P0 数据泄露。
为什么不能靠 GORM Scopes 或 context 透传 tenant_id 来做字段隔离
Scopes 和手动注入 tenant_id 看似简单，但实际运行中极易失效：
-
GORM的Raw()、Joins()、Count()、Unscoped()等方法会绕过 Scopes，只要调用一次就可能跨租户读取 - 把
tenant_id塞进context.Context再一路传到 DAO 层拼 SQL，等于把隔离责任甩给每个开发者——中间任何一层漏传、错传或复用旧 context，数据就裸奔 - 软删除字段（如
deleted_at）若没和tenant_id同级约束，Unscoped().Where("id = ?", x)可直接绕过租户检查 - 测试难覆盖：单元测试常 mock DB 层，无法暴露真实 SQL 漏条件问题
PostgreSQL schema 隔离必须配合 search_path + sync.Map 缓存
schema 隔离不是“建个 schema 就完事”，关键在连接初始化时绑定上下文，并复用连接池：
- 每个租户对应一个 PostgreSQL schema（如
tenant_abc），建表语句统一加CREATE TABLE tenant_abc.users - 不要手写表名拼接（如
"tenant_abc.users"），破坏 ORM 抽象、难测、易出错；应使用SET search_path TO tenant_abc让所有后续查询自动落在该 schema - 用
sync.Map缓存租户专属的*sql.DB实例：tenantID → *sql.DB，避免每次请求都重连 - 首次获取时调用
db.Exec("SET search_path TO " + tenantID)，之后该连接所有Query/Exec自动生效 - 连接池需限流：
db.SetMaxOpenConns(5)，否则 1000 租户 × 默认 100 连接 = 10 万连接，直接打崩 PG
MySQL 下没有 search_path，硬上 schema 隔离等于自废武功
MySQL 不支持 search_path，也没有原生 schema 级权限隔离能力。所谓“MySQL schema 隔离”实际只能靠库名（database name）区分，但这带来致命问题：
立即学习“go语言免费学习笔记（深入）”；
- 每个租户一个 database（如
saas_tenant_123），就必须为每个租户新建一个*sql.DB实例 -
database/sql连接池按*sql.DB实例维护，无法跨库复用，1000 租户 ≈ 1000 个独立连接池 - K8s 下扩缩容反模式：连接池健康检查、空闲连接回收、OOM 风险全部指数级放大
- 若仍想用 MySQL，唯一可行路径是字段隔离 + RLS 替代方案（如
WHERE tenant_id = ?全局强制 + 中间件校验 + 所有缓存键带租户前缀）
Redis 缓存键和 Elasticsearch 索引必须带租户上下文
数据库层做了隔离，但缓存和搜索层常被忽略，成为越权高发区：
- Redis 键名不能是
user:123，必须是tenant:abc123:user:123；更稳妥做法是用租户 ID 映射 Redis DB 编号（如SELECT 10对应tenant_abc），但需确认客户端支持动态SELECT - Elasticsearch 必须用索引前缀隔离，如
tenant_abc_products、tenant_def_orders；禁用共享索引 +tenant_id字段过滤，因 ES 查询不保证字段过滤绝对生效（尤其聚合、脚本、reindex 场景） - 所有缓存操作前，必须从 Gin
c.Get("tenant_id")或 JWT claim 中提取，不可从 URL、query 或 body 解析——这些都不可信
真正难的不是“怎么写代码”，而是 schema 名称如何生成、租户生命周期事件（创建/停用/迁移）如何触发 DB 初始化与清理、以及跨 schema 的 DDL 如何同步。这些没法靠框架自动完成，得自己写带事务回滚和断点续传的迁移工具。
