SetMaxOpenConns应设为MySQL max_connections的70%～80%（如151则设100～120），SetMaxIdleConns设为其1/2左右（如50），并必须配SetConnMaxLifetime（2～5分钟），初始化后务必调db.Ping()验证。
db.SetMaxOpenConns() 和 db.SetMaxIdleConns() 怎么设才不翻车
这两个参数不是拍脑袋定的，得看你的数据库实际承载能力和请求特征。设太高，MySQL 会报 Too many connections；设太低，请求排队等待连接，延迟飙升。
常见错误现象：压测时 QPS 上不去，pprof 显示大量 goroutine 卡在 db.Query 或 db.Exec，日志里反复出现 waiting for connection。
-
db.SetMaxOpenConns(n)：建议设为数据库最大连接数的 70%～80%，例如 MySQL 默认max_connections=151，那这里设100比较安全 -
db.SetMaxIdleConns(n)：通常设为MaxOpenConns / 2左右（如50），避免空闲连接长期占用资源又不至于频繁新建 -
db.SetConnMaxLifetime(time.Hour)必须配，否则连接老化后仍被复用，可能触发 MySQL 的Lost connection
为什么 initDB() 里没调用 SetXXX 就会连崩
Golang 的 database/sql 包对连接池有默认行为：MaxOpenConns = 0（无限制）、MaxIdleConns = 2、ConnMaxLifetime = 0（永不过期）。线上跑几天，连接数就爆表，MySQL 直接拒绝新连接。
使用 GORM 时也一样——它底层还是走 sql.DB，gorm.Open() 不会自动帮你设池参数。
- 必须在
InitDB()初始化后立刻调用三个Set*方法，顺序不重要，但缺一不可 - 别把配置写死在代码里，从环境变量或配置文件读取，比如
os.Getenv("DB_MAX_OPEN") - 容器环境下注意：K8s Pod 重启后连接池重建，
ConnMaxLifetime能防止旧连接残留引发的 timeout
db.QueryRow() 和 db.Query() 在高并发下为啥特别容易卡住
它们本身不卡，卡的是背后没释放的连接。一个没加 rows.Close() 的 db.Query()，或者没处理 error 就跳过的 db.QueryRow().Scan()，都会让连接一直挂在池里，直到超时或进程退出。
更隐蔽的问题是：你在 handler 里用了 defer rows.Close()，但 handler 提前 return 了（比如校验失败），defer 还没执行，连接就泄漏了。
- 所有
db.Query()后必须显式rows.Close()，别依赖 defer（除非你能 100% 确保流程走到最后） -
db.QueryRow().Scan()出错时，也要检查err == sql.ErrNoRows，否则连接不会归还 - 用
pprof/net/http/pprof查/debug/pprof/goroutine?debug=2，搜database/sql关键字，能快速定位泄漏点
连接池和 Gin 中间件怎么配合才不互相拖累
连接池本身是全局复用的，但中间件如果在每个请求里都做 db.Ping() 或新建事务，就会变成性能黑洞。尤其 Recovery() 和 Logger() 这类全局中间件，每秒几千次 Ping() 直接打穿数据库健康检查接口。
真实场景中，90% 的中间件根本不需要碰 DB。
- 把 DB 操作严格收口到 service 层，中间件只做鉴权、限流、日志等无状态操作
- 需要 DB 的中间件（如 JWT token 刷新），务必用 context 超时控制，例如
ctx, cancel := context.WithTimeout(c.Request.Context(), 300*time.Millisecond) - 健康检查路由
r.GET("/healthz", func(c *gin.Context) { c.Status(200) })绝对不要挂任何 DB 相关中间件
mysqladmin extended-status | grep Threads_connected 和应用侧的 db.Stats() 输出，比任何文档都管用。 
