SetMaxOpenConns应设为数据库max_connections值的60%～80%（如max_connections=200，则设120～160），预留余量给备份、监控及其他服务；设0或远超上限均会触发“Too many connections”错误。
SetMaxOpenConns设多少才不触发“Too many connections”
直接看数据库服务端的 max_connections 值，别拍脑袋。云数据库（如阿里云 RDS、腾讯云 CDB）通常默认是 100～200，查法：
SHOW VARIABLES LIKE 'max_connections';
假设返回 200，SetMaxOpenConns 就该设成 120～160（60%～80%）。留出余量给备份、监控、其他微服务共用同一实例。
-
SetMaxOpenConns = 0：等于不限制，QPS 上去立刻报错Too many connections -
SetMaxOpenConns = 500：远超 MySQL 服务端上限，连接请求直接被拒，P99 延迟从 50ms 拉到 800ms+ - 云环境更保守：按 CPU 核数 × 20 估算上限（比如 4 核 → 不超过 80），别套物理机配置
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对设置
只调 SetMaxIdleConns 不设 SetConnMaxLifetime，等于让空闲连接赖在池里不走。云厂商的 NAT 网关或防火墙会在 3～5 分钟后静默断连，下次复用就报 read: connection reset by peer。
-
SetMaxIdleConns设为SetMaxOpenConns的 1/2～2/3（例如最大 120 → 空闲设 40～80） -
SetConnMaxLifetime推荐 2～5 分钟：RDS 主备切换快，设 2 分钟更安全；自建库可放宽到 5 分钟 - 千万别设
0或time.Hour：长期存活连接容易在 DB 侧积压idle in transaction，锁资源、占内存、触发上下文切换风暴
db.Ping() 不是可选项，是启动必做动作
gorm.Open() 只初始化结构体，不建真实连接。日志里写 “DB initialized” 并不代表能连上——第一笔查询才真正拨号。这时候网络不通、密码错、DNS 解析失败，全堆在首请求上，轻则接口超时，重则首页白屏。
- v2 中
db.Ping()已废弃，必须用db.Session(&gorm.Session{}).Ping() - 必须紧接
gorm.Open()后执行，并检查 error，失败要 panic 或重试 - 漏掉这步，本地测得再稳，上云后遇到跨可用区网络抖动就崩
云数据库驱动参数要显式加 parseTime=true 和 loc=Asia/Shanghai
云数据库时间字段常以 datetime 或 timestamp 存储，不加 parseTime=true 会导致 time.Time 字段读出来是空值或零值；不指定 loc，UTC 服务器会把时间全转成 UTC，业务显示错 8 小时。
- DSN 示例：
user:pass@tcp(aliyun-rds-host:3306)/db?charset=utf8mb4&parseTime=true&loc=Asia/Shanghai - SQLite / SQL Server 驱动不支持该参数，忽略即可；达梦 DM8 要确认驱动版本是否兼容
- 这个参数和连接池无关，但漏了会导致数据读取逻辑异常，比连接池问题更难排查
实际部署时最容易被跳过的，是 db.Session(&gorm.Session{}).Ping() 这一行 —— 它不报错、不打日志、不阻塞启动，但一旦出问题，所有请求都卡在连接获取阶段，监控上看就是 QPS 归零、延迟飙升，而数据库连接数却很低。
