SetMaxOpenConns设太高或太低均会导致连接数异常暴涨：过高时超数据库max_connections引发等待与重试，过低则并发阻塞、频繁建连失败；应设为max_connections的60%～80%，并配对设置SetMaxIdleConns和SetConnMaxLifetime，且必须调用db.Session(...).PingContext()主动探活并精准识别网络类错误重试。
SetMaxOpenConns设太高还是太低都会让连接数暴涨
连接数“只增不减”不是流量大了才发生，而是配置和行为不匹配的必然结果。设 SetMaxOpenConns 为 500，但 MySQL 的 max_connections 只有 200，那第 201 个请求就会卡在等待队列里，连接池内部计数却持续上涨——因为 database/sql 会不断尝试新建连接直到超时，而失败连接不会立刻释放。
反过来，设得太低（比如 10），20 个 goroutine 并发查用户，全部阻塞在 db.Query 上，连接池反复创建、失败、重试，日志里满屏 dial tcp: i/o timeout 或 connection refused，监控看到的是 InUse=0、Idle=0、WaitCount 暴涨。
- 查 MySQL 实际上限：
SHOW VARIABLES LIKE 'max_connections'; - 生产环境推荐值：
SetMaxOpenConns = max_connections × 0.6～0.8（如 200 → 120～160） - 云数据库（RDS/Cloud SQL）更保守：按 CPU 核数 × 20 估算，别照搬物理机配置
SetMaxIdleConns 和 SetConnMaxLifetime 不配对用等于埋雷
只调 SetMaxIdleConns 却不设 SetConnMaxLifetime，空闲连接就真“闲”到死。云环境 NAT 网关或 SLB 默认 3～5 分钟断连，连接池还傻等复用，下次一取就报 read: connection reset by peer——这时连接池会自动新建连接，旧连接却没被回收，InUse 不降、Idle 不升，总数越滚越大。
-
SetMaxIdleConns应为SetMaxOpenConns的 1/2～2/3（如 Open=120 → Idle=40～60） -
SetConnMaxLifetime必须设：云环境推荐 2～5 分钟；自建 MySQL 可设 5 分钟；千万别设0或time.Hour - 长期存活连接易在 DB 侧积压
idle in transaction，锁表、占内存、触发上下文切换风暴
漏掉 db.Ping() 导致首请求全量失败，间接推高连接峰值
gorm.Open() 只是初始化结构体，不建真实连接。很多服务启动日志写着 “DB ready”，其实第一笔查询才真正拨号——这时候 DNS 解析失败、密码错、网络不通，全堆在首请求上，Goroutine 卡住、超时重试、连接池反复扩容，瞬间就把连接数顶上去。
- v2+ GORM 中
db.Ping()已弃用，必须用：db.Session(&gorm.Session{}).Ping() - 必须紧接
gorm.Open()后执行，并检查 error；失败应 panic 或阻塞重试，不能静默忽略 - 运行中可每 30 秒调一次
db.Session(...).PingContext(ctx)主动探活
没做连接错误识别 + 重试，业务层反复触发连接重建
GORM 不自动重连，也不区分错误类型。你 catch 到 err != nil 就直接返回，前端重刷、重提交、重轮询，每个请求都走一遍连接获取 → 失败 → 释放 → 再获取，连接池像抽风一样伸缩。真正的连接断开错误必须精准识别：
- MySQL：
errors.As(err, &mysql.MySQLError{})后判断myErr.Number() == 2003 || 2013 - PostgreSQL：
errors.As(err, &pq.Error{})后判断pqErr.Code[0:2] == "08" - 通用兜底：错误字符串含
"dial tcp"、"i/o timeout"、"connection refused" - 仅这类错误才重试 1～2 次，间隔 100–500ms；主键冲突、校验失败等业务错误绝不重试
连接池爆满从来不是单一参数问题，而是配置、探活、错误处理三者脱节的综合结果。最容易被跳过的其实是 db.Session(...).Ping() 这一行——它不解决性能，但决定服务启得动、撑得住、扛得稳。
