连接池“失效”实为连接僵死，需配置SetConnMaxLifetime、强制Ping校验、精准识别连接错误并有限重试。
连接池“失效”其实是连接僵死，不是GORM坏了
所谓连接池失效，90%不是GORM本身出问题，而是空闲连接被中间件（NAT、防火墙）或数据库（MySQL wait_timeout）静默断开后，GORM仍试图复用——下次查询直接报read: connection reset by peer或invalid connection。GORM 不会主动探测连接是否还活着，它只管从池里取、用完放回。真正该动的是*sql.DB的配置，不是重写 GORM。
-
SetConnMaxLifetime必须设（推荐2 * time.Minute～5 * time.Minute），强制连接在过期前被销毁，避免复用已断连 -
SetMaxIdleConns不能大于SetMaxOpenConns，否则 Go 1.12+ 会 panic 报"max idle conns exceeds max open conns" - 云环境（如阿里云 RDS）更需保守：若 MySQL
wait_timeout = 3600（1小时），SetConnMaxLifetime务必设为55 * time.Minute或更低
db.Ping()不是可选动作，是启动必检项
很多服务日志显示“DB initialized”，但第一笔查询才真正拨号。DNS 解析失败、密码错误、网络不通全堆在首请求上，导致接口首屏白屏或超时。这不是连接池失效，是初始化漏校验。
- 必须在
gorm.Open()后立刻调db.DB().Ping()，失败就 panic 或阻塞重试，别等上线才暴露 - 运行中建议每 30 秒执行一次
db.DB().PingContext(ctx)，配合健康检查端点（如/health/db）暴露状态 - 不要只依赖 HTTP handler 里的
db.First()来“顺便检测”，那已经晚了
怎么判断真是连接断了，而不是 SQL 写错了
用db.Error != nil判断连接失败是最大误区。db.Error是操作级封装，gorm.ErrRecordNotFound、1062 Duplicate entry、甚至context.DeadlineExceeded都会进这里。误判会导致反复重建连接，加剧 MySQL 的Too many connections雪崩。
- 必须穿透 GORM 封装，对
result.Error做类型断言：
PostgreSQL 驱动（github.com/lib/pq）→ 断言*pq.Error，检查Code[0:2] == "08"（如"08006"）
MySQL 驱动（github.com/go-sql-driver/mysql）→ 断言*mysql.MySQLError，检查Number()是否为2002（can't connect）、2013（lost connection） - 别碰
1040 Too many connections：这是服务端拒绝新连接，重连只会让情况更糟，该扩配或限流 - SQLite / SQL Server 场景下，可兜底捕获
os.IsTimeout(err)或 I/O 类错误，但不建议当作连接异常主路径
业务层要不要加重试？加在哪？
重试不是万能膏药。事务内盲目重试会破坏原子性；非连接类错误（如唯一约束冲突）重试毫无意义。只有明确识别出连接类异常后，才值得在业务查询层加有限重试。
- 仅当
isConnectionError(err)返回 true 时，才在 100–500ms 后重试 1–2 次（别超过 3 次） - 事务场景必须先
tx.Rollback()再重试，否则后续Begin()可能卡住；用RetryTransaction封装比手写 for 循环更安全 - HTTP handler 里不要写
db, _ := gorm.Open()——这会泄漏连接池，全局单例*gorm.DB才是正解
连接池配置、主动探活、错误精准识别，三者缺一不可。最容易被忽略的是：你写的“重连逻辑”往往根本没机会执行——因为连接池还没僵死，只是某条连接在复用时突然断了，而你的代码还在等它返回结果。
