直接多次调用database/sql的Open会导致连接池爆炸、DNS压力大、无法动态切换租户，且PostgreSQL中search_path不跨连接复用，必须为每个租户缓存独立*sql.DB实例并设置search_path。
为什么不能直接用 database/sql 的 Open 多次连接不同 schema
Go 标准库的 database/sql 本身不感知 schema 概念，它只管连接池和语句执行。PostgreSQL 或 MySQL 中的 schema（或 database）是服务端逻辑隔离单位，不是客户端连接参数。你调用 sql.Open("postgres", "host=... dbname=tenant_a") 是创建一个专属连接池，但租户数一多（比如上百），连接池爆炸、DNS 解析压力、连接超时、pgbouncer 不兼容等问题立刻浮现。更关键的是：无法动态切换，每次换租户就得 Close() 再 Open()，业务层根本没法做请求级路由。
用连接字符串参数动态拼接 dbname 或 search_path 更可行
对 PostgreSQL，最轻量的方式是在连接时通过 search_path 控制默认 schema；对 MySQL，则必须用 dbname 参数指定 database（MySQL 没有 schema-level search_path）。实际操作中：
- PostgreSQL：在构建 DSN 时追加
options=-c+search_path%3Dtenant_123（URL 编码后），这样所有未带 schema 前缀的表名（如SELECT * FROM users）自动落在tenant_123下 - MySQL：DSN 中直接写
dbname=tenant_123，且确保该 database 已存在、用户有权限 - 避免在 SQL 里硬写
tenant_123.users—— 这会让 ORM（如 GORM）生成的查询失效，也破坏迁移工具链 - 注意：
search_path只影响当前连接生命周期，不能跨连接复用；连接池中每个连接都需独立设置
GORM v2 如何安全注入租户上下文
GORM 支持 Session 和 WithContext，但它的 WithContext 默认不透传到连接层。正确做法是：在中间件或 handler 中从请求提取租户标识（如 header X-Tenant-ID），然后用 db.Session(&gorm.Session{Context: ctx}) 创建会话，并在该会话上拼接租户专属 DSN 或设置 search_path。示例关键点：
- 不要全局复用一个
*gorm.DB实例做多租户，而应为每个租户缓存一个*gorm.DB（按租户 ID 为 key 的sync.Map） - 首次访问某租户时，调用
gorm.Open(postgres.Open(dsn), &gorm.Config{...})构建新实例，DSN 含动态search_path - 缓存的
*gorm.DB必须设置SetMaxOpenConns(5)等限制，否则单租户撑爆数据库连接 - 租户 DB 实例无需手动 Close —— 它们共享底层
*sql.DB连接池，GORM 会复用
Schema 隔离失败的三个典型错误现象
多租户跑着跑着查出别的租户数据，往往不是代码写错，而是配置或边界没控住：
-
PgSQL 错误 ERROR: relation "users" does not exist——search_path拼错或 schema 不存在，检查是否漏建CREATE SCHEMA tenant_xxx - 事务跨租户污染：A 请求用
tenant_a的 DB 实例开启事务，B 请求误用同一实例执行tenant_b查询 —— 根源是租户 DB 实例被意外共享（比如放在 struct field 而非 local var） - 连接池混用：多个租户共用一个
*sql.DB，但没在Exec/Query前显式SET search_path—— 此时连接可能复用前一次的路径，导致查错 schema
租户隔离真正的复杂点不在“怎么切”，而在“怎么保证每次请求都落到正确的连接上下文里”——中间件拦截、context 传递、DB 实例生命周期管理，三者缺一不可。漏掉任意一环，数据就可能串。
