GORM连接池不可重置，强行调用gorm.Open重建*gorm.DB实例会导致连接泄漏、配置丢失和并发错乱；正确做法是配置SetConnMaxLifetime与SetConnMaxIdleTime，依赖database/sql连接池自动淘汰失效连接，并通过驱动错误码精准识别断连。
不能重置，也不该重置 —— GORM 的连接池没有“重置”语义，强行重建 *gorm.DB 实例是典型误操作，会导致连接泄漏、配置丢失、并发错乱。
为什么调用 gorm.Open 重建 DB 实例是错的
很多人看到 connection refused 或 i/o timeout 就立刻 gorm.Open 新实例，这会：
- 旧
*sql.DB连接池未Close()，导致 fd 泄漏、内存持续增长 - 新池默认
SetMaxOpenConns(0)（无上限），可能瞬间打爆 MySQL 的max_connections - 日志配置、回调函数、PrepareStmt 等全部重载，旧 session 状态（如事务、preload）彻底丢失
- 在 Revel/Gin 等框架中，若把该操作放在 handler 里，每请求一次就新建一个池 → 几秒内
too many open files
真正该做的：让连接池自己清理失效连接
GORM 不提供重连 API，它完全依赖 database/sql 连接池的自动行为。关键不是“重置”，而是“让池正确识别并淘汰坏连接”：
- 必须设置
db.DB().SetConnMaxLifetime(7 * time.Hour)（比 MySQLwait_timeout小 5～10 分钟）—— 这是防止僵尸连接的唯一有效手段 - 设置
db.DB().SetConnMaxIdleTime(30 * time.Minute)，避免空闲太久被中间件（如 RDS Proxy）静默断开 - 不要依赖
db.Ping()做健康检查：它只测“此刻能否建新连”，不验证池中已有空闲连接是否还活着 - 真实失效暴露在
Query()或Exec()阶段，此时连接池会自动丢弃该连接、新建一个替代
如何安全地替换底层 *sql.DB（极少数必须场景）
仅当遇到驱动级严重 bug（如某版本 pgx 持久连接卡死）且无法升级时，才考虑手动切换底层连接池。此时必须：
- 先调用原
db.DB().Close()，确保所有连接释放（注意：此操作会阻塞直到所有活跃查询完成） - 用新配置调
sql.Open()创建*sql.DB，再传给gorm.Open(..., gorm.Config{...})构造新*gorm.DB - 确保所有业务代码已停止使用旧
*gorm.DB实例（比如通过 context cancel 或全局 mutex 控制） - 切勿在 HTTP handler 或 goroutine 中动态切换；必须在服务启动/滚动更新等可控生命周期点执行
最常被忽略的一点：连接池“异常”往往不是连接本身的问题，而是错误码没被正确识别 —— 比如 PostgreSQL 的 "08006" 和 MySQL 的 2013 必须穿透 result.Error 做类型断言，否则你永远不知道该不该告警，而不是该不该“重置”。
