SetMaxOpenConns必须设为MySQL max_connections的60%～80%（如后者为200则设120～160），并配对设置SetMaxIdleConns（为Open值的1/2～2/3）和SetConnMaxLifetime（云环境推荐2～5分钟），且启动时必须调db.Ping()验证连接。
SetMaxOpenConns 必须和 MySQL max_connections 对齐，否则限流无效
限流不是靠拍脑袋设个 100 就完事。GORM 本身不实现限流逻辑，它只是把 SetMaxOpenConns 透传给底层 *sql.DB；真正起作用的是这个值是否与数据库服务端的并发连接上限匹配。
常见错误现象：Too many connections 报错、P99 延迟从 50ms 拉到 800ms+、云数据库 RDS 连接数突增触发告警。
- 查 MySQL 实际上限：
SHOW VARIABLES LIKE 'max_connections';，假设返回200 -
SetMaxOpenConns应设为120～160（60%～80%），留余量给备份、监控、其他服务 - 云数据库（如阿里云 RDS）建议更保守：按每核 ≈20 连接估算，别套物理机配置
- 设成
0或500：MySQL 很快报错；设成10：20 个 goroutine 并发时全卡在等连接，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 * time.Minute更安全；自建 MySQL 可设5 * time.Minute - 千万别设成
0或time.Hour：长期存活连接易在 DB 侧积压idle in transaction，锁资源、占内存、触发上下文切换风暴 - Go 1.12+ 会校验：
SetMaxIdleConns(n)若大于当前SetMaxOpenConns值，运行时直接 panic，错误信息为"max idle conns exceeds max open conns"
GORM v2 初始化后必须手动调 db.DB() 才能生效
gorm.Open() 返回的是 *gorm.DB，它封装了 *sql.DB，但连接池参数不会自动继承。不显式拿到原生句柄并设置，所有配置都无效。
- 正确顺序：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})→sqlDB, err := db.DB()→ 再调sqlDB.SetMaxOpenConns(100)等 - 常见误配：只传
&gorm.Config{}却没调db.DB().SetMaxOpenConns(20)→ 池仍用默认值MaxOpenConns=0（无限制） - 若用
sql.Open()初始化，同样要走db.SetMaxOpenConns()流程，不能跳过
db.Ping() 只验证首连，真健康检查得靠 SetConnMaxIdleTime + 定期 Stats
db.Ping() 只建一个连接执行 SELECT 1，它不检查池中已有空闲连接是否还活着。MySQL 的 wait_timeout=300 或 RDS Proxy 主动断连后，陈旧连接仍躺在池里，直到下次 Query() 才暴露 i/o timeout。
- 必须紧接
gorm.Open()后加db.Ping()，否则首请求失败会导致线上首屏白屏 -
SetConnMaxIdleTime（Go 1.15+）可强制清理空闲太久的连接，推荐设为1 * time.Minute - 配合
db.Stats()定期打点：重点关注InUse（是否长期 >95%）、Idle（是否长期接近 0）、WaitCount（是否持续上涨） - k8s readiness probe 若只调
db.Ping()，可能误判服务可用；应结合db.Stats().WaitCount做判断
实际部署时最容易被忽略的点是：连接池参数不是“设完就跑”，而是需要跟数据库服务端配置、云环境网络策略、应用并发模型三者对齐。哪怕数字全对，漏掉 db.Ping() 或 SetConnMaxIdleTime，照样在线上凌晨三点开始报 invalid connection。
