gorm.Open()必须全局只调用一次，否则导致连接池泄漏；正确做法是启动时初始化单例*gorm.DB并复用，同时须配置SetMaxOpenConns、SetMaxIdleConns和SetConnMaxLifetime，并立即db.Ping()校验连接。
gorm.Open() 只能调用一次，否则连接池会泄漏
反复在 handler 或 goroutine 里调用 gorm.Open()，表面看能“拿到新连接”，实则每次都在新建 *sql.DB 实例——旧的连接池不会自动关闭，db.Close() 又常被忽略，最终导致文件描述符耗尽、MySQL 报 Too many connections。这不是并发问题，是资源管理失控。
正确做法是应用启动时初始化一次，全局复用同一个 *gorm.DB 实例：
- 用包级变量 +
init()函数（适合简单服务） - 或注入到结构体字段（如
type Service struct { DB *gorm.DB }），由依赖注入容器统一管理生命周期 - 切勿在 HTTP handler 内写
db, _ := gorm.Open(...)
SetMaxOpenConns 必须设，且不能为 0
SetMaxOpenConns 默认是 0，即无上限。上线后只要并发稍高，MySQL 的 max_connections 很快打满，P99 延迟从 50ms 暴涨到 800ms+。这不是代码慢，是连接池和数据库“呼吸节奏”没对上。
必须手动设置，并严格按数据库真实容量来：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先查 MySQL：执行
SHOW VARIABLES LIKE 'max_connections';，假设返回 200 - 设
db.DB().SetMaxOpenConns(120)（取 60%～80%，留余量给备份、监控等其他服务） - 云数据库（如阿里云 RDS）更保守：按每核 ≈20 连接估算，别套物理机配置
- 设成 500 → MySQL 立即拒绝新连接；设成 10 → 20 个 goroutine 并发查用户，全卡在等连接
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 * time.Minute更安全（适配云数据库主备切换） - 注意：
SetMaxIdleConns(n)若大于当前SetMaxOpenConns值，Go 1.12+ 会 panic，错误信息为"max idle conns exceeds max open conns"
db.Ping() 是启动必检项，不是可选动作
sql.Open() 或 gorm.Open() 只是初始化连接池结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上，导致线上首屏白屏。
务必在初始化后立即调用：
if err := db.Ping(); err != nil { log.Fatal("DB ping failed:", err) }- 后续还可定期用
db.Stats()监控InUse、Idle、WaitCount，及时发现连接堆积或等待尖峰
连接池参数调优不是一劳永逸的事，它和你的 QPS、平均 SQL 耗时、DB 部署形态强相关。上线后盯紧 WaitCount > 0 和 InUse == MaxOpen 这两个信号，它们比任何压测报告都诚实。
