必须为每个数据库创建独立*gorm.DB实例，因其实例封装连接池、回调链、日志器等不可共享组件；复用同一变量会导致连接泄漏、事务失效、日志污染；需分别调用gorm.Open并单独配置。
不能靠改一个 *gorm.DB 变量来“切换”数据库——每个库必须是独立的 *gorm.DB 实例，否则事务失效、连接池错乱、日志和回调互相污染。
为什么 gorm.Open 不能复用同一个变量
*gorm.DB 不是轻量上下文，它内部封装了 *sql.DB、回调链（Callbacks）、日志器（Logger）、插件（如 prometheus、opentelemetry）和连接池配置。两个不同 DSN 的数据库，哪怕只是库名不同，也必须调用两次 gorm.Open，分别赋值给不同变量（如 userDB、logDB）。
复用同一变量（比如 db = gorm.Open() 覆盖赋值）会导致前一个库的连接池未关闭，连接泄漏；userDB.Transaction() 中调用 logDB.Create()，后者完全游离在事务外；驱动导入漏下划线（import _ "gorm.io/driver/mysql" 缺少 _）时，gorm.Open 不报错，但首次查询卡死或返回 "invalid connection"。
如何安全注册多个 GORM 实例
启动时显式初始化，避免 init() 隐式加载；每个实例用唯一变量名，并单独配置连接池与中间件。
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 用工厂函数替代全局
var：例如NewUserDB(cfg) (*gorm.DB, error)，错误可透出、便于测试 - DSN 特殊字符必须编码：PostgreSQL 密码含
/或@时，需用url.QueryEscape处理，否则报"pq: password authentication failed"且难以定位 - 每个
*gorm.DB单独加中间件：userDB.Use(logger.New())，别用gorm.DefaultCallback全局注册，否则所有库共享同一日志行为 - 模型迁移必须按库执行：
userDB.AutoMigrate(&User{})和logDB.AutoMigrate(&Log{})是两套独立操作
运行时动态路由到对应 GORM 实例
靠 context.Context 透传目标库标识，由统一路由层（非 ORM 层）解析并返回对应 *gorm.DB，禁止在 DAO 层硬编码 if tenant == "shanghai" { return userDB } 等分支。
常见错误包括：
- 把租户 ID 放路径（如
/t/abc123/users），中间件解析后塞进context，但 handler 忘了从ctx.Value(tenantDBKey)取值，继续用错库 - 误以为 Gin Group 或 mux Subrouter 能控制数据库——它们只影响 URL 匹配，不触达 DB 层
- 试图用
SET search_path（PostgreSQL）或USE database（MySQL）动态切 schema，结果连接池复用导致数据串库
正确做法是：为每个租户调用一次 gorm.Open，生成独立 *gorm.DB 实例，用 sync.Map 缓存映射（tenantID → *gorm.DB），入口中间件校验租户有效性后注入 context，handler 显式取值。
GORM 多实例共存的三个雷区
驱动导入漏下划线、DSN 特殊字符未编码、事务跨库无效——这三点最容易在本地开发跑通、上线后才暴露。
尤其要注意：userDB.Transaction() 内调用 logDB.Create() 看似合理，实则后者完全游离在事务外；GORM 做不了分布式事务，业务层得用补偿逻辑，而不是寄希望于 ORM 自动兜底。
