中小SaaS用tenant_id字段隔离即可；但长期维护、租户超50或有安全审计要求时，应采用schema级隔离——它靠数据库原生能力兜底，避免ORM漏加tenant_id导致跨租户读取，且PostgreSQL中仅需SET search_path，轻量可靠。
Go 里该用 tenant_id 字段隔离，还是为每个租户建独立 schema？
结论很明确：中小 SaaS 用 tenant_id 字段隔离够用；但只要团队有长期维护意愿、租户数预期超 50、或对数据安全/审计有要求，就该直接上 schema 级隔离——这是 Go 微服务中真正可落地、可运维的默认方案。
字段隔离看着省事，实际埋雷最多：GORM 自动生成的 Count、FirstOrInit、关联预加载（Preload）等操作极易漏加 WHERE tenant_id = ?，线上查错成本远高于初期多写几行切换逻辑。而 schema 隔离靠数据库原生能力兜底，哪怕 DAO 层写错 SQL，也不会跨租户读到脏数据。
-
schema方案在 PostgreSQL 中只需一句SET search_path TO tenant_abc，连接池复用无压力 - 别手写表名拼接（如
tenant_abc.users），既难测试又破坏 ORM 抽象；用search_path是最轻量且兼容所有驱动的方式 - MySQL 不支持
search_path，若必须用它，优先考虑分库（dbname=tenant_abc），但得接受连接池爆炸风险——这不是 Go 的问题，是 MySQL 架构限制
怎么安全地动态切换租户 DB 连接？别存全局变量，也别传 context 到 DAO 层
常见错误是把 tenantID 塞进 context.Context，然后在每个 db.Query 前手动拼 tenant_abc. 前缀——这等于把数据隔离责任甩给每个业务开发者，漏一次就是 P0 故障。
正确做法是让连接本身“知道”它属于谁：用 sync.Map 缓存租户专属的 *sql.DB 实例，在首次请求时初始化并设置 search_path，后续复用即可。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次 HTTP 请求都调用
sql.Open？绝对不行——连接泄漏、OOM、启动慢全找上门 - 必须调用
db.SetMaxOpenConns和db.SetConnMaxLifetime，否则高并发下连接数会失控（尤其 K8s 中 Pod 重启频繁时） - 缓存 key 推荐用
subdomain（如acme.example.com → acme），比用 UUID 或内部 ID 更易排查、更贴近真实路由逻辑
租户标识从哪来？别信 X-Tenant-ID 请求头
明文 header 是最弱的身份凭证，中间代理、CDN、甚至前端调试都可能篡改。生产环境必须从可信源提取租户上下文：JWT 解析结果、或网关鉴权后注入的 context.Value。
示例场景：用户访问 acme.example.com，API 网关解析其 JWT，确认 claims.tenant_id == "acme" 后，才把该值注入下游服务的 context。这样即使攻击者伪造 header，也会在网关层被拒。
- GIN 中间件里用
c.GetHeader("X-Tenant-ID")直接取值？这是开发自测可以，上线前必须删掉 - 租户元数据（如 subdomain → db config 映射）应存在主库（
tenants表），而不是硬编码或配置文件——否则新增租户要发版 - 如果用子域名路由，记得在 TLS 终止层（如 Nginx / ALB）透传 Host，Go 服务才能拿到原始
r.Host
为什么没人真用「每租户一个 database」？不是技术不行，是 Go 的连接池模型不兼容
PostgreSQL 支持无限建库，但 Go 的 database/sql 包按 *sql.DB 实例管理连接池——意味着每租户一个 dbname，就得持有一个独立 *sql.DB，连接数随租户线性增长。1000 个租户 ≈ 1000 个连接池，每个池默认最大 0（即无限），不出三天数据库就报 too many clients。
这不是 PostgreSQL 的锅，是 Go 底层设计使然。想绕开？只能自己实现连接池代理或改用 pgxpool（但它也不解决 schema 切换问题，只是池管理更细粒度）。
- DB 级隔离唯一可行的场景：极少数金融级客户，合同强制要求物理隔离 + 独立云账号 + 独立 VPC——这时你不是在写 SaaS，是在交付私有化部署包
- 哪怕选 DB 级，也别让 Go 服务直连；应该由网关或 sidecar 负责路由，Go 服务只连固定库，靠 proxy 动态转发
- Schema 级已能通过
pg_dump -n tenant_xyz实现单租户备份，运维友好性不输 DB 级
真正卡住多数团队的，从来不是“怎么实现”，而是“谁来保证每次查询都不越界”。所以别纠结抽象层，把隔离逻辑沉到连接池这一层，比在 ORM 上打补丁可靠十倍。
