Gin 不支持多库动态配置，需手动在中间件中完成解析、查表、加载、注入四步；Group/Router 无法控制数据库选择；租户 DB 必须预加载、缓存并显式取值；读写分离需业务代码严格控制；sync.Map 使用需判空防 panic。
Gin 框架本身不提供“多库动态配置”能力——它压根不管数据库连哪，也不参与连接创建或切换逻辑。所谓“动态”，必须由你手动在中间件里完成解析、查表、加载、注入这四步，否则所有 handler 都会继续用错的 *sql.DB 实例。
为什么 Gin 的 Group/Router 无法控制数据库选择
Group（如 r.Group("/api/v1")）只影响路径匹配和中间件执行顺序，对数据库连接零感知。常见错误包括：
- 在
v1 := r.Group("/api/v1")下注册的 handler 仍直接调用全局变量db，结果所有租户共用同一连接池 - 把
/t/{tenant}/users这类路径当“路由数据库”的信号，但c.Param("tenant")只返回字符串，不会自动触发sql.Open - 虽在中间件里解析了
X-Tenant-ID并塞进context，但 handler 忘了用ctx.Value(tenantDBKey)取值，仍 fallback 到全局db
正确做法：租户 DB 实例必须预加载 + 缓存 + 显式取值
数据库连接选择必须发生在 handler 执行前，且不能依赖 HTTP 方法或路径前缀做判断。关键动作有三：
- 启动时按租户 ID 预加载独立
*sql.DB实例，各自调用SetMaxOpenConns和SetConnMaxLifetime，避免流量倾斜拖垮其他租户 - 用
sync.Map缓存映射关系：tenantDBs.LoadOrStore(tenantID, newDB(cfg))，防止每次请求都重连 - 入口中间件校验租户标识（支持从
X-Tenant-ID、Host或 JWTsub字段提取），映射后注入context；handler 中必须显式写db := ctx.Value(tenantDBKey).(*sql.DB)，禁止 fallback
读写分离不能交给 Gin 或 ORM 自动识别
Go 生态里没有“根据 SQL 类型自动路由读库/写库”的通用机制。真实场景中：
- 事务内所有操作必须走同一个
*sql.DB实例，跨库事务会直接报错或数据不一致 - 读写分离由业务代码严格控制：写操作用
writeDB，非事务性读用readDB，且两者必须是不同预加载的实例 - 若租户配置变更（如主库地址更新），需触发
sync.Map.LoadAndDelete+ 重建实例，而非热 reload 连接池（Go 的*sql.DB不支持运行时替换底层连接）
最容易被忽略的一点：sync.Map 是并发安全的，但它的 LoadOrStore 返回的是 value, loaded bool，如果 handler 里没检查 loaded 就直接类型断言，遇到缓存未命中时会 panic。务必加判空或用 if db, ok := ctx.Value(tenantDBKey).(*sql.DB); !ok { /* 处理错误 */ }。
