必须显式调用 SetMaxOpenConns（默认0=无限制，生产环境危险），并配合 SetMaxIdleConns、SetConnMaxLifetime 和 SetConnMaxIdleTime；全局单例复用 *gorm.DB，通过 db.DB().Stats() 和数据库视图验证生效。
gorm.DB().SetMaxOpenConns() 必须显式调用
默认值是 0，代表无限制——这在生产环境等于埋雷。哪怕只启 50 个 goroutine 并发执行 db.Create()，也可能瞬间占满数据库的 max_connections，触发 Too many connections 或 PostgreSQL 的 too many clients already 错误。
必须在 gorm.Open() 后立刻获取底层 *sql.DB 实例并设置：
-
db.DB().SetMaxOpenConns(100)：硬性上限，建议设为数据库服务端max_connections的 70%～80%，留出空间给备份、监控等后台连接 - 若数据库
max_connections = 256，这里设180比设256更安全 - 设成负数或
0等同于放弃控制，不是“自动适配”，而是“听天由命”
SetMaxIdleConns 和 SetConnMaxLifetime 要配合用
只设 SetMaxOpenConns 不够。空闲连接不回收、老化连接不刷新，会导致连接池堆积无效连接，最终仍被数据库侧主动断开或超时踢出，引发 connection refused 或 driver: bad connection。
-
db.DB().SetMaxIdleConns(50)：通常设为SetMaxOpenConns的一半左右，避免频繁建连/销毁开销 -
db.DB().SetConnMaxLifetime(time.Hour)：强制连接在 1 小时后释放重建，防 ProxySQL、RDS 代理、防火墙等中间件静默断连后连接卡死 -
db.DB().SetConnMaxIdleTime(time.Minute * 30)（Go 1.15+）：空闲超 30 分钟的连接直接丢弃，比靠SetConnMaxLifetime更精细
别在每次请求里 new gorm.DB 实例
常见错误是把 gorm.Open() 写在 HTTP handler 里，每来一个请求就新建一个 *gorm.DB。这样连接池完全失效——每个实例都带独立池子，且默认 SetMaxOpenConns(0)，等于裸连。
- 全局单例初始化：用
sync.Once或init()函数只创建一次*gorm.DB - 确认你用的是同一个实例：打印
fmt.Printf("%p", db)，多个 handler 输出地址应一致 - GORM 本身不管理连接，它只是
database/sql的封装；连接池行为完全取决于底层*sql.DB的配置
验证连接池是否生效的最快方法
别只看代码有没有调用那几个 SetXXX 方法。真正要看运行时行为：
- 查数据库当前连接数：
SHOW PROCESSLIST（MySQL）或SELECT * FROM pg_stat_activity（PostgreSQL），观察活跃连接是否稳定在你设的SetMaxOpenConns附近，而非持续攀升 - 用
db.DB().Stats()打印实时统计：MaxOpenConnections、OpenConnections、IdleConnections，确认没长期卡在 high idle 或 stuck in use - 压测时故意让某个查询 sleep 2 秒，再并发发起 200 请求——如果只有前
SetMaxOpenConns个能立刻执行，其余阻塞等待，说明限流生效；如果全部立刻执行或报错，说明配置没起作用
实际中最容易被忽略的，是 SetConnMaxLifetime 和 SetConnMaxIdleTime 的组合使用。很多团队只设了最大连接数，却没处理连接老化问题，结果上线几小时后开始出现偶发的连接中断，排查半天才发现是 RDS 自动回收了空闲超时连接，而你的池子里还拿着已失效的句柄。
