SetMaxOpenConns必须与MySQL的max_connections对齐，推荐设为后者的60%～80%（如max_connections=200，则设120～160），并配SetMaxIdleConns（1/2～2/3）和SetConnMaxLifetime（2～5分钟），初始化后须调db.Ping()验证连接。
SetMaxOpenConns 值设太高或太低都会出事
这个值不是拍脑袋定的，必须和数据库服务端的 max_connections 对齐。查 MySQL 当前限制用：SHOW VARIABLES LIKE 'max_connections';。假设返回 200，SetMaxOpenConns 就该设成 120～160（60%～80%），留余量给备份、监控、其他服务，也防突发毛刺。
常见错误：
-
SetMaxOpenConns设为 0 或 500：MySQL 很快报Too many connections，P99 延迟从 50ms 拉到 800ms+ - 设太低（比如 10）：20 个 goroutine 并发查用户，全卡在等连接，QPS 上不去，平均延迟反而升高
- 云数据库（如阿里云 RDS）建议更保守：按每核 ≈20 连接估算，别硬套物理机配置
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，锁资源、占内存、触发上下文切换风暴
别在每次 HTTP 请求里 new *gorm.DB 实例
常见错误是把 gorm.Open() 写在 handler 里，每来一个请求就新建一个 *gorm.DB。这样连接池完全失效——每个实例都带独立池子，且默认 SetMaxOpenConns(0)，等于裸连。
正确做法：
- 全局单例初始化：用
sync.Once或init()函数只创建一次*gorm.DB - 确认你用的是同一个实例：打印
fmt.Printf("%p", db)，多个 handler 输出地址应一致 - GORM 本身不管理连接，它只是
database/sql的封装；连接池行为完全取决于底层*sql.DB的配置
启动时漏掉 db.Ping() 会导致首请求失败
sql.Open() 或 gorm.Open() 只是初始化连接池结构，不建真实连接。很多服务日志里写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上。
必须紧接 db, err := gorm.Open(...) 后加 db.Session(&gorm.Session{}).Ping()（GORM v2 中 db.Ping() 已弃用），并检查 error。
验证连接池是否生效的最快方法不是看代码有没有调那几个 SetXXX 方法，而是运行时查数据库当前连接数：SHOW PROCESSLIST（MySQL）或 SELECT * FROM pg_stat_activity（PostgreSQL），观察活跃连接是否稳定在你设的 SetMaxOpenConns 附近，而非持续攀升。
