SetMaxOpenConns=0不是不限制，而是不设上限，导致连接池无节制新建连接，直至MySQL报Too many connections；必须显式设置合理值，且SetMaxIdleConns不能大于它，ConnMaxLifetime应比wait_timeout小5–10分钟。
为什么 SetMaxOpenConns=0 会炸 MySQL
默认值是 0，不是“不限制”，而是“不设上限”——连接池会无节制新建连接，直到 MySQL 报 Too many connections。这不是 GORM 的 bug，是 database/sql 的设计：它把上限交由使用者显式控制。
-
SetMaxOpenConns(0)→ 连接数随并发请求线性增长，DB 端扛不住就断连或拒绝新连 - 线上服务若没配这个参数，哪怕只跑几个 goroutine，高峰期也可能触发 MySQL 连接数满
- 别信“先上线再调参”，必须在
gorm.Open()后立刻调用db.DB().SetMaxOpenConns(n)
SetMaxIdleConns 大于 SetMaxOpenConns 就 panic
Go 1.12+ 对空闲连接数做了硬校验，不是警告，是运行时直接 crash，错误信息为 "max idle conns exceeds max open conns"。
- 典型误配：
sqlDb.SetMaxOpenConns(5)后又执行sqlDb.SetMaxIdleConns(10)→ 立即 panic - 正确顺序：先设
SetMaxOpenConns，再设 ≤ 它的SetMaxIdleConns - 生产建议值：
SetMaxIdleConns = SetMaxOpenConns × 0.5（如开 20 连，空闲留 10） - 设成 0 表示禁用空闲池，每次 Query 都建新连，性能极差，仅用于调试
ConnMaxLifetime 不是保活，是强制淘汰
SetConnMaxLifetime 不发心跳、不检测连通性，只是计时器一到就关连接。它的作用是让连接在数据库主动断连前先被 Go 主动丢弃。
- MySQL 默认
wait_timeout=300s（5 分钟），若 Go 侧不设SetConnMaxLifetime，连接可能在池里“假活”到被取出时才暴露i/o timeout或invalid connection - 推荐设为比 DB 的
wait_timeout小 5～10 分钟，例如 MySQL 设 300s，则 Go 侧设240 * time.Second -
db.Ping()检不出这种问题——它只建一个新连测通，不扫描池中已有连接是否已失效
连接数怎么估？看并发峰值和单次耗时
连接池不是越大越好，也不是越小越省资源；它得匹配你的实际负载模型。估算公式很简单：MaxOpenConns ≈ 并发请求数 × 单次 DB 操作平均耗时 / 平均响应时间，但更实用的是按场景拍：
- HTTP API 服务：QPS 100，平均 DB 耗时 50ms → 峰值并发约 5，
SetMaxOpenConns(10～15)足够（留余量） - 后台任务型服务（如定时 job）：单个 job 执行 2s，同时跑 10 个 → 至少需要 10 连，设
20更稳 - 混合场景（API + job）：分开初始化两个
*gorm.DB实例，各自配池参数，避免互相挤占 - 别盲目抄别人配置：K8s 中 pod 副本数 × 每副本池大小 = 实际打到 DB 的总连接数，这个总和不能超 MySQL
max_connections
真正容易被忽略的点是：连接池参数必须在应用启动时一次性设置完成，且必须通过 db.DB() 获取原生句柄后调用；任何在 handler 或 service 层临时改参数的行为都无效，因为 *sql.DB 的池行为不可动态重置。
