SetMaxOpenConns 应设为数据库 max_connections 的 60%～80%（如200则设120～160），云数据库更保守（4核RDS建议80）；SetMaxIdleConns 与 SetConnMaxLifetime 必须配对设置，前者为后者的1/2～2/3，后者推荐2～5分钟；必须调用 db.DB().Ping() 验证连接，并在启动早期完成所有连接池参数配置。
SetMaxOpenConns 必须和 MySQL max_connections 对齐
设成 0 或拍脑袋填 500，线上立刻报 Too many connections；设成 10 又会让并发请求排队等连接，QPS 上不去、延迟飙升。真实值必须查数据库服务端上限：
执行 SHOW VARIABLES LIKE 'max_connections';，假设返回 200，SetMaxOpenConns 就该设为 120～160（60%～80%）。
留余量给备份、监控、其他微服务，也防突发流量毛刺。
云数据库（如阿里云 RDS）更保守：按每核 ≈20 连接估算，别套物理机配置。
- 自建 MySQL：设为服务端
max_connections的 60%～80% - 阿里云 RDS（4 核）：建议上限设 80 左右，而非直接用 200
- 千万别设 0 —— 默认无限制，等于把闸门全打开
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() 或 sql.Open() 只初始化连接池结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上，导致首屏白屏或接口超时。
必须紧接 db, err := gorm.Open(...) 后面加 db.DB().Ping()，并检查 error：
- 用
db.DB().Ping()，不是db.Ping()（后者不存在） - 若用
sql.Open()初始化，同样要db.Ping() - 配合
db.DB().Stats()定期打点：重点关注InUse（是否长期 >95%）、Idle（是否长期接近 0）、WaitCount（是否持续上涨）
GORM v2 不自动透传连接池参数，必须手动调 db.DB()
gorm.Open() 返回的是 *gorm.DB，它底层封装了 *sql.DB，但所有连接池行为（SetMaxOpenConns 等）都委托给后者。GORM 自身不暴露这些参数，你必须先用 db.DB() 提取出来再设置。
常见错误是写完 gorm.Open 就以为万事大吉，忘了这一步 —— 结果池子还是默认值（MaxOpenConns=0，MaxIdleConns=2），线上一压就崩。
- 正确顺序：open → ping →
db.DB().SetMaxOpenConns(...)→db.DB().SetMaxIdleConns(...)→db.DB().SetConnMaxLifetime(...) - 别在中间插其他逻辑，尤其别等第一次查询后再设 —— 那时连接已开始创建，参数无效
- 所有设置必须在应用启动早期完成，不能懒加载或运行时动态改
最常被忽略的一点：连接池参数不是“设一次就完事”，而是要和数据库服务端配置、应用并发模型、部署拓扑（是否跨 AZ、是否走 NAT）联动调整。一个参数改了，另外两个几乎必然要跟着动。
