GORM无断线重连能力，可靠恢复需三要素：精准识别连接错误（如MySQL 2003/2013、PostgreSQL "08"码）、合理配置连接池四参数（MaxOpenConns/MaxIdleConns/ConnMaxLifetime/ConnMaxIdleTime）、业务层条件重试可恢复错误（如driver.ErrBadConn）并启动时Ping检测。
GORM 本身不提供“断线重连”能力，也从不建议你手动调用 gorm.Open 来恢复连接 —— 那只会泄漏连接池、耗尽文件描述符、触发 MySQL 的 1040: Too many connections。真正可靠的故障恢复，靠的是三件事：精准识别连接类错误、合理配置连接池生命周期、以及在业务层做轻量级重试。
怎么判断是连接断了，而不是 SQL 写错了
不能靠 result.Error != nil 或 db.Error != nil 判断连接失败。这些 error 可能是 gorm.ErrRecordNotFound、UNIQUE constraint failed、甚至 context canceled，和网络无关。
必须穿透 GORM 封装，对 error 做类型断言，提取底层驱动错误码：
- PostgreSQL（
github.com/lib/pq）：断言为*pq.Error，检查pqErr.Code[0:2] == "08"（如"08006"表示连接被拒绝） - MySQL（
github.com/go-sql-driver/mysql）：断言为*mysql.MySQLError，检查myErr.Number()是否为2003（无法连接）、2013（查询中连接丢失） - 通用兜底：错误字符串含
"dial tcp"、"i/o timeout"、"connection refused"，基本可判定为网络层断连
连接池参数必须配齐，缺一不可
只设 SetMaxOpenConns 是无效的。云环境（如阿里云 RDS）下，NAT 网关或防火墙会在 3～5 分钟静默关闭空闲连接，若不主动清理，下次复用就会报 read: connection reset by peer。
这四个参数必须一起配：
-
sqlDB.SetMaxOpenConns(120)：按数据库max_connections的 60%～80% 设（查法：SHOW VARIABLES LIKE 'max_connections'） -
sqlDB.SetMaxIdleConns(40)：设为MaxOpenConns的 1/3～1/2，避免空闲连接堆积 -
sqlDB.SetConnMaxLifetime(3 * time.Minute)：强制连接在 2～5 分钟内重建，适配云环境主备切换与中间件超时 -
sqlDB.SetConnMaxIdleTime(30 * time.Second)：让空闲连接更快释放，减少僵死连接残留
漏掉任意一个，都可能在上线后某天凌晨突然出现大量 driver: bad connection 或连接数暴涨。
重试逻辑只能加在业务层，且必须带条件
事务里不能无脑重试；非事务查询也不能每次失败都重试。只有明确属于连接类、可恢复的错误才值得重试 1～2 次，且需指数退避。
典型可重试错误包括：
driver.ErrBadConn- MySQL 错误码
1205（死锁）、2013（连接丢失） - PostgreSQL 错误码以
"08"开头 -
context.DeadlineExceeded（配合短超时上下文使用时）
绝对不要重试：
-
gorm.ErrRecordNotFound（记录不存在） -
UNIQUE constraint failed（唯一键冲突） -
ERROR: current transaction is aborted（SQLSTATE25P02，事务已崩，不是连接问题）
重试前务必确保已调用 tx.Rollback()（事务场景），否则后续 Begin() 可能卡死。
启动时必须 Ping，否则首请求大概率失败
gorm.Open() 只初始化结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号 —— 这时候 DNS 解析失败、密码错误、网络不通，全堆在用户首屏上。
v2 中 db.Ping() 已弃用，正确写法是：
if err := db.Session(&gorm.Session{}).Ping(); err != nil {
log.Fatal("failed to ping DB:", err)
}别跳过这步。它成本极低，却能提前暴露 90% 的配置类故障。
最易被忽略的一点：连接池健康不是“一次配置永久有效”的事。它依赖驱动错误码识别精度、连接生命周期参数匹配度、以及业务层是否对可恢复错误做了最小化重试 —— 三者缺一，都会让“看似稳定”的服务在某个网络抖动后雪崩式降级。
