GORM中无法运行时“切换”连接池，因gorm.DB在gorm.Open时即绑定底层sql.DB和驱动参数；必须初始化独立masterDB与slaveDB实例，由Repository层显式路由，配合PingContext健康检查与failover-controller决策。
不能靠“切换”连接池实现主备容灾——GORM 里没有无感切换连接池这回事，所有所谓“切换”本质都是请求路由变更或实例替换。
为什么 gorm.DB 无法运行时“切换”连接池
GORM 的 *gorm.DB 实例在 gorm.Open() 时就绑定了底层 *sql.DB 和驱动参数，它不是上下文容器，而是有状态的封装体。调用 db.Session(&gorm.Session{NewDB: true}) 只是新建一个会话副本，不改变原连接池；试图复用同一个变量赋值新 gorm.Open() 结果，会导致前一个连接池未关闭、连接泄漏、事务失效、日志器错乱。
常见错误现象：
- 主库宕机后，代码里写
db = gorm.Open(newDSN, ...)，但旧连接池还在后台 leak - 用
db.Exec("SET search_path = tenant_abc")伪切换 schema，结果连接池复用导致跨租户数据污染 - 误以为 GORM 的
WriteMode/ReadMode插件能接管主从健康状态，实际它只做简单路由，不感知Seconds_Behind_Master或PingContext超时
真正可行的主备切换路径：Repository 层直控 + 独立实例
主备切换必须绕过 ORM 自动路由逻辑，在 Repository 层显式区分 masterDB 和 slaveDB 实例，并由独立控制器管理状态。
实操要点：
- 启动时初始化两个独立
*gorm.DB：一个连主库（masterDB），一个连从库（slaveDB），各自调用.DB().SetMaxOpenConns()等配置 - 写操作永远走
masterDB，且每次执行前必须masterDB.PingContext(ctx)；失败则触发健康检查，不自动 fallback - 读操作默认走
slaveDB，但从库超时或延迟超标（如SHOW SLAVE STATUS中Seconds_Behind_Master > 30）时，需主动禁用该实例，而非降级到主库——否则主库被打爆 - 切换决策由单独 goroutine（如
failover-controller）监听 etcd 或本地心跳文件，变更后更新atomic.Value存储当前有效 master 地址，Repository 层只读取，不参与判断
连接池参数配置与数据库类型强相关
MySQL 和 PostgreSQL 对连接池敏感度不同，硬套统一参数容易出问题。
关键差异点：
- PostgreSQL 的
max_connections默认常为 100，而 MySQL 可能设为 500+；达梦等国产库默认更小（如 100），需提前确认上限 -
SetConnMaxLifetime对 PostgreSQL 更重要：连接空闲太久易被中间件（如 pgbouncer）断开，建议设为2h；MySQL 可设为7h -
SetConnMaxIdleTime必须小于数据库侧的wait_timeout（MySQL）或tcp_keepalives_idle（PostgreSQL），否则连接池会持续返回"invalid connection" - 从库连接超时（如
dial tcp 10.0.1.2:3306: i/o timeout）只影响读，不应触发主库接管全部流量——业务层若自行降级到主库，又没加限流，就是雪崩起点
冷启动与配置失效时的兜底必须带哈希校验
配置中心（如 Nacos、etcd）不可靠是常态，尤其容器环境下 viper.WatchConfig() 常因 overlayfs 失效。不能依赖它实时更新连接池。
安全做法：
- 启动时加载本地兜底配置（如
db-fallback.yaml），含主从地址、超时时间、连接池参数 - 该文件内容做 SHA256 校验，每次读取先比对哈希，避免因文件残留或覆盖失败导致静默使用脏配置
- 首次连接失败后，立刻 fallback 到该本地配置，不等待配置中心恢复——否则服务启动直接 503
- 连接池初始化失败（如 DSN 密码含
@未url.QueryEscape）时，gorm.Open不报错，但首次Query卡死或返回"invalid connection"，需在 init 阶段强制PingContext验证
最易被忽略的一点：主库返回 ERROR 1205 (40001): Deadlock found 是事务冲突，不是宕机，不该触发任何主从切换动作——这类错误必须由业务重试逻辑处理，混进容灾流程只会让系统更不稳定。
