默认SetMaxOpenConns=0完全不够，会直接压垮MySQL；必须设为数据库max_connections的60%～80%，如查得200则设120～160，并配SetMaxIdleConns≤该值、SetConnMaxLifetime略小于数据库wait_timeout。
默认 SetMaxOpenConns=0 会直接压垮 MySQL
够用？完全不够。GORM 的 SetMaxOpenConns 默认值是 0，意思是“不限制最大打开连接数”。这不是宽松，是放任——只要并发请求一上来，每个 goroutine 都可能新建连接，直到 MySQL 报 Too many connections。线上常见现象：P99 延迟从 50ms 暴涨到 800ms+，错误日志里全是连接拒绝。
必须手动设置，且不能拍脑袋：
- 先查数据库真实容量：
SHOW VARIABLES LIKE 'max_connections'; - 生产环境取其 60%～80%，例如返回
200，就设120～160 - 云数据库（如阿里云 RDS）更保守，建议按每核 ≈20 连接估算
SetMaxIdleConns 默认 2 太小，但乱设会 panic
Go 标准库 database/sql 默认 SetMaxIdleConns=2，GORM 继承该行为。这个值在低流量场景下看似够用，但遇到突发请求时，空闲连接池瞬间被掏空，新请求只能排队建连，延迟毛刺明显。
但它不是“调大就行”：
-
SetMaxIdleConns必须 ≤ 当前SetMaxOpenConns值，否则运行时直接 panic，报错"max idle conns exceeds max open conns" - 推荐设为
SetMaxOpenConns的 1/2 到 2/3（比如开 100 连接，空闲留 40～60） - 千万别在没设
SetMaxOpenConns前就调SetMaxIdleConns，此时虽不 panic，但行为不可控
SetConnMaxLifetime=0 导致 invalid connection 频发
默认 SetConnMaxLifetime=0 表示连接永不过期。问题在于：MySQL 服务端有 wait_timeout（通常 300s），NAT 网关或云厂商 Proxy 也会在 3～5 分钟后静默断连。这些“僵尸连接”仍躺在池里，直到下次被取出执行 Query() 才暴露 invalid connection 或 read: connection reset by peer。
解决方式很明确：
- 设
SetConnMaxLifetime为比数据库wait_timeout小 5～10 分钟（如 MySQL 是 300s，Go 侧设240 * time.Second） - 云环境更激进些：直接设 2～5 分钟，主备切换快，旧连接早丢早重建
- 注意：
SetConnMaxLifetime不发心跳，也不检测连通性，它只是个计时器——到期就关，不等 DB 来杀
db.Ping() 不是可选动作，漏掉就等于首请求裸奔
gorm.Open() 只初始化结构，不建真实连接。很多服务启动日志写着 “DB initialized”，其实第一笔查询才真正拨号。这时候网络不通、密码错、DNS 解析失败，全堆在首请求上——前端白屏、接口超时、监控告警一起炸。
必须紧接 gorm.Open() 后加健康检查：
- GORM v2 中
db.Ping()已弃用，改用db.Session(&gorm.Session{}).Ping() - 只验证一次不够，k8s readiness probe 若只调这个，可能误判；真正稳的机制是
SetConnMaxLifetime+ 应用层重试 - 别依赖
defer db.Close()来“兜底”——它只关底层*sql.DB，GORM 实例仍持有失效指针，且完全不触达连接池参数
连接池不是开箱即用的黑盒，它的三个核心参数（SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime）必须成套配置，且顺序不能错：先设上限，再设空闲，最后设寿命。漏掉任何一个，都可能在线上某个凌晨三点突然让你收到一条“数据库连接打满”的告警。
