必须为每个数据库单独初始化*gorm.db实例，gorm不支持单实例自动路由异构库；需分别导入驱动、调用gorm.open()创建独立实例，并显式配置连接池、时区及ssl等参数。
如何用 GORM 动态创建多个数据库连接实例
不能靠单个全局 gorm.DB 实例切换数据库——GORM 本身不支持运行时“切库”，必须为每个数据库维护独立的 *gorm.DB 实例。核心是把连接配置和实例封装成可复用的构造函数。
常见错误是试图调用 db.Exec("USE other_db") 或修改 db.Statement.ConnPool，这在并发下极易出错，且对 PostgreSQL/SQLite 等不通用。
- 按数据库用途（如
user_db、log_db）定义结构体或 map 存储不同*gorm.DB - 使用
gorm.Open()分别初始化，传入对应gorm.Dialector（如mysql.Open(dsn)） - 务必调用
db.Set("gorm:table_options", "ENGINE=InnoDB")等连接级配置，而非复用前一个实例的设置 - 连接池需单独配置：
db.Config.ConnPool = &sql.DB{...}不推荐；应通过sql.Open()获取原生*sql.DB后传给gorm.Open()
DB 实例如何安全注入到业务逻辑中
直接全局变量或包级变量存多个 *gorm.DB 会导致测试难、依赖不清晰、热重载失败。推荐显式传递或使用依赖注入容器（如 uber/fx），但最小可行方案是构造一个 DBRouter 结构体。
典型场景：用户服务查 user_db，审计日志写 log_db，两者不能共用事务上下文。
- 定义
type DBRouter struct { User *gorm.DB; Log *gorm.DB; Cache *gorm.DB } - 初始化时统一处理错误：
if err != nil { return nil, fmt.Errorf("failed to open user_db: %w", err) } - 业务函数接收
*DBRouter，而不是某个具体*gorm.DB，避免误用错库 - 不要在 handler 层做
router.User.First(...)，而应封装进userRepo.FindByID()，把库选择逻辑收口
事务跨数据库一定失败，怎么设计替代方案
GORM 的 Transaction() 只作用于单个 *gorm.DB 实例，跨库事务本质不可行（除非用 XA，但 MySQL 8+ 已弃用，且 PG 不支持）。强行包装只会掩盖数据不一致风险。
真实需求往往是“用户创建成功后记日志”，这不是强一致性事务，而是最终一致性。
- 优先用本地事务 + 消息队列（如
go-sqlmock测试时可 mock 发送行为） - 若必须同步，用 TCC 模式：先
User.Create()，成功后再Log.Create()，失败则手动回滚用户记录（注意幂等） - 避免在
defer中操作另一库——panic 时可能只执行一半，造成脏数据 - PostgreSQL 用户注意：
database/sql的BeginTx()不会自动传播到其他*sql.DB，即使 DSN 完全相同
MySQL 多租户场景下，为什么不能靠 db.Table("tenant_001.users") 切库
用动态表名模拟多库（如 tenant_{id}.users）看似简单，但会快速触达 MySQL 单库性能瓶颈，且无法利用原生库级权限隔离、备份粒度、资源限制等能力。
更严重的是，GORM 的 Table() 只改表名，不改连接目标，所有请求仍打向同一个物理数据库节点。
- 真正切库必须换
*gorm.DB实例，哪怕只是 DSN 中的dbname参数不同 - 租户路由逻辑建议放在中间件或 repository 初始化阶段，而非每次查询都解析 URL 或 header
- 注意连接数爆炸：100 个租户 × 每个 10 连接 = 1000 连接，需提前配好 MySQL
max_connections和 Go 连接池MaxOpenConns - SQLite 场景例外：可用
sqlite.Open("file:tenant1.db?cache=shared")，但无法并发写同一文件
最易被忽略的一点：不同数据库实例的 Migrate 行为必须独立执行，db.AutoMigrate() 不会跨实例同步 schema。漏掉某个库的 migration，上线后立刻报 ERROR: relation "users" does not exist。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
