SetMaxOpenConns=0会触发连接风暴，因其表示无限制，导致每个goroutine都新建连接直至MySQL报Too many connections；必须设为数据库max_connections的60%～80%，并配对设置SetMaxIdleConns和SetConnMaxLifetime，且启动后立即db.Ping()验证。
连接池没配对，再快的代码也会在数据库门口堵成春运。
为什么SetMaxOpenConns=0会直接触发连接风暴
这个值设为 0 表示不限制最大打开连接数，GORM 底层的 *sql.DB 会持续新建连接直到 MySQL 报 Too many connections。这不是“偶尔多连几个”，而是并发请求一上来就批量拨号——每个 goroutine 都以为自己该拿新连接，结果服务端瞬间被打满，P99 延迟从 50ms 拉到 800ms+。
-
SetMaxOpenConns必须和数据库的max_connections对齐：查SHOW VARIABLES LIKE 'max_connections'，取其 60%～80%（如返回 200，则设 120～160） - 云数据库（如阿里云 RDS）更保守：按每核 ≈20 连接估算，别套物理机配置
- 设太高（如 500）→ MySQL 主动拒绝；设太低（如 10）→ 请求排队等连接，QPS 上不去，延迟反而升高
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对用
只调 SetMaxIdleConns 不设 SetConnMaxLifetime，等于让空闲连接赖着不走。云环境 NAT 网关或防火墙会在 3～5 分钟后静默断连，下次复用直接报 read: connection reset by peer。
-
SetMaxIdleConns推荐设为SetMaxOpenConns的 1/2 到 2/3（如最大 100 → 空闲设 40～60） -
SetConnMaxLifetime推荐 2～5 分钟：云数据库主备切换快，设 2 分钟更安全；自建 MySQL 可设 5 分钟 - 千万别设成
0或time.Hour：长期存活连接容易在 DB 侧积压idle in transaction，锁资源、占内存、触发上下文切换风暴
漏掉 db.Ping() 是首请求失败的头号原因
gorm.Open() 只是初始化结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上，导致首屏白屏或超时。
- 必须紧接
db, err := gorm.Open(...)后加db.Session(&gorm.Session{}).Ping()（GORM v2 中db.Ping()已弃用） - 检查 error，不忽略；否则首请求失败率飙升，监控里 P99 延迟毛刺明显
- 这个动作不是“可选健康检查”，而是连接池真正进入可用状态的必要步骤
连接断开后不能靠重连 DB 实例来救
遇到 connection refused 或 i/o timeout 就去调 gorm.Open()？这是最危险的应对方式。它会新建连接池、加载配置、注册回调，导致：
- 内存泄漏：旧连接池未
Close()，新池不断创建 - 连接数爆炸：每个
Open()默认开启最大连接数，叠加后远超 DB 承载上限 - 配置覆盖：如
PrepareStmt、日志级别被重复设置
正确做法是复用已初始化的 *gorm.DB，仅对其底层 *sql.DB 调用 Ping() 检测，并依赖连接池自动重建空闲连接——这才是 database/sql 设计的本意。
连接池不是开关，是呼吸系统；调参不是填数字，是匹配数据库的脉搏节奏。最容易被忽略的，是把 SetConnMaxLifetime 当成可选项，而它其实是防止连接陈旧失效的底线保障。
