SetMaxOpenConns必须设为MySQL max_connections的60%～80%（如200则设120～160），且需配SetMaxIdleConns（≤其值）、SetConnMaxLifetime（2～5分钟）并调用db.Session().Ping()验证连接。
SetMaxOpenConns 必须设，且不能为 0 或拍脑袋填
MySQL 报 Too many connections 的第一原因就是这个值没设或设成 0。默认值是 0（无限制），上线后并发一上来，连接数直接打满数据库。查当前 MySQL 最大连接数：SHOW VARIABLES LIKE 'max_connections';，假设返回 200，SetMaxOpenConns 就该设成 120～160（60%～80%）。云数据库（如阿里云 RDS）更保守：按每核 ≈20 连接估算，别套物理机配置。
常见踩坑点：
-
SetMaxOpenConns(500)→ 数据库瞬间拒绝新连接，P99 延迟从 50ms 拉到 800ms+ -
SetMaxOpenConns(10)→ 20 个 goroutine 并发查用户，全卡在等连接，QPS 上不去 - 设太高又没配
SetMaxIdleConns→ 空闲连接堆积，DB 侧出现大量idle in transaction
SetMaxIdleConns 要 ≤ SetMaxOpenConns，否则 panic
Go 1.12+ 对空闲连接数做了硬校验：SetMaxIdleConns 若大于当前 SetMaxOpenConns 值，运行时直接崩溃，错误信息是 "max idle conns exceeds max open conns"。典型误配：db.SetMaxOpenConns(5); db.SetMaxIdleConns(10) → 立即 crash。
稳妥做法：
- 先调
SetMaxOpenConns，再调SetMaxIdleConns - 生产环境推荐设为
SetMaxOpenConns的 1/2 到 2/3（例如开 100 连接，空闲留 40～60） - 不设
SetMaxOpenConns（即保持 0）时，SetMaxIdleConns(10)不会 panic，但空闲连接实际不可控，不建议
SetConnMaxLifetime 和 SetConnMaxIdleTime 要配对用，防静默断连
云环境（RDS、ProxySQL、NAT 网关）通常在 3～5 分钟后静默断开空闲连接，下次复用直接报 read: connection reset by peer 或 invalid connection。只设 SetMaxIdleConns 不设生命周期，等于让空闲连接赖着不走。
推荐组合：
-
SetConnMaxLifetime(2 * time.Minute)：云数据库主备切换快，设短更安全；自建 MySQL 可设 5 分钟 -
SetConnMaxIdleTime(30 * time.Minute)（Go 1.15+）：比SetConnMaxLifetime更精细，空闲超 30 分钟直接丢弃 - 千万别设
time.Hour或 0：长期存活连接易在 DB 侧积压资源、触发上下文切换风暴
db.Ping() 必须紧跟 gorm.Open() 后执行，且得用 db.Session().Ping()
gorm.Open() 只初始化结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 失败，全堆在首请求上，导致首屏白屏或接口超时。
v2 中 db.Ping() 已被弃用，必须用：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
if err != nil {
log.Fatal(err)
}
if err := db.Session(&gorm.Session{}).Ping(); err != nil {
log.Fatal("failed to ping DB:", err)
}注意：这只能验证“此刻能建一个连并执行 SELECT 1”，不检查池中已有空闲连接是否还活着。真正失效发生在 Query() 归还连接之后，所以 SetConnMaxLifetime 是唯一能缓解的机制。
连接池参数不是写完就生效，必须通过 db.DB() 获取底层 <em>sql.DB</em> 实例后设置；GORM 自身不管理连接，它只是封装。最容易被忽略的是：多个 handler 打印 fmt.Printf("%p", db) 地址不一致 → 说明你在每次请求里 new 了 gorm.DB，连接池完全失效。
