GORM不支持连接池级故障自动转移，因gorm.DB仅持单个sql.DB实例，无多端点路由或健康探测能力；可靠failover须依赖数据库中间件（如ProxySQL）、云厂商高可用地址或网络层实现，GORM只需合理配置连接池、精准识别驱动错误码（如PG的"08"前缀、MySQL的2013）并定期Ping探活。
GORM 本身不支持连接池级的故障自动转移（failover），它依赖底层 database/sql 连接池和驱动行为，真正的“转移”必须由数据库层或代理层完成。
为什么不能在 GORM 层做 failover
GORM 的 *gorm.DB 对象只持有一个 *sql.DB 实例，它没有内置多 endpoint 路由、健康探测、写/读分离或主备切换逻辑。所谓“自动转移”，如果靠 GORM 自己轮询多个 DSN 并在报错时切下一个，会带来严重问题：
- 每次查询都可能触发重试 + 切换，放大延迟和错误率
- 事务无法跨连接维持，
Begin()后连接中断会导致状态不一致 - 连接池参数（如
SetMaxOpenConns）对每个 DSN 独立生效，资源不可控 - 驱动错误码（如 PostgreSQL 的
"08"类）只反映当前连接异常，不代表其他地址就可用
生产环境真正可行的 failover 方案
必须把故障转移下沉到更底层，GORM 只需保持连接池配置合理、错误识别准确即可：
- 用数据库中间件：如 ProxySQL（MySQL）、pgBouncer + etcd（PostgreSQL），它们监听后端节点健康状态，自动将请求路由到可用实例；GORM 只连中间件地址，完全无感
-
用云厂商高可用地址：阿里云 RDS、腾讯云 CDB、AWS RDS 都提供一个“主备切换不中断”的虚拟 IP 或域名（如
xxx.mysql.rds.aliyuncs.com），底层 DNS 或 LB 自动更新解析；GORM 连这个地址即可 -
应用层 DNS 缓存要设短：避免系统级 DNS 缓存导致切换后仍打向旧 IP；Go 默认使用 cgo resolver，建议启动时加
GODEBUG=netdns=go强制走 Go 原生解析，并设置net.Resolver.PreferGo = true -
配合连接池探活：即使用了高可用地址，也要定期
db.Session(&gorm.Session{}).Ping()，否则连接池里积压的僵死连接会在首次复用时集中爆发read: connection reset by peer
误用“手动重连”反而破坏 failover
常见反模式是捕获错误后自己拼新 DSN、再 gorm.Open() —— 这不仅无法保证事务连续性，还会绕过连接池复用，造成连接数暴涨。尤其注意：
-
db.Error != nil不代表连接断了，可能是业务错误（如gorm.ErrRecordNotFound），直接重连会掩盖真实问题 - 仅当错误能穿透到驱动原生类型且匹配连接类码时才可视为“需转移信号”，例如：
– PostgreSQL：*pq.Error.Code以"08"开头（如"08006"）
– MySQL：*mysql.MySQLError.Number()是2013（lost connection）或2002（can't connect） - 即便识别出连接错误，GORM 也不该主动切 DSN，而应让连接池在下次
GetConn时自然新建连接——前提是你的 DSN 指向的是高可用入口
真正关键的不是“怎么切”，而是“切给谁”。别在 ORM 层补救架构缺陷，把 failover 交给更合适的位置：数据库代理、云服务或网络层。GORM 做好连接池参数、错误识别、探活三件事，就已经为故障转移铺平了路。漏掉任何一环，自动转移都会变成自动雪崩。
