Gin中db.SetMaxOpenConns(0)上线即炸，因其表示无上限，连接数随并发线性增长，MySQL迅速报Too many connections；Gin不管理连接池，需在启动时全局配置*sql.DB参数，且SetMaxIdleConns必须≤SetMaxOpenConns，否则Go 1.12+直接panic。
为什么Gin里db.SetMaxOpenConns(0)上线就炸
因为SetMaxOpenConns(0)不是“不限制”，而是“无上限”，连接数随并发线性增长，MySQL很快报Too many connections。Gin本身不管理连接池，它只用*sql.DB，所有池参数都得手动设——且必须在应用启动时一次性配置，不能在handler里反复调sql.Open。
- 错误写法：
func handler(c *gin.Context) { db, _ := sql.Open(...) }→ 每次请求新建池，fd耗尽、database is closed频发 - 正确姿势：全局初始化一次
*sql.DB（或*gorm.DB），注入到service层复用 - GORM用户注意：
gorm.Open返回*gorm.DB，但池参数要通过gormDB.DB()拿到原生句柄再设
SetMaxIdleConns大于SetMaxOpenConns会panic
Go 1.12+做了硬校验，SetMaxIdleConns(10)紧接着SetMaxOpenConns(5)会直接crash，错误信息是"max idle conns exceeds max open conns"。这不是警告，是运行时崩溃。
- 必须先调
SetMaxOpenConns(n)，再调SetMaxIdleConns(m)，且确保m ≤ n - 生产环境推荐
SetMaxIdleConns = SetMaxOpenConns × 0.5（如Open=20 → Idle=10） - 没设
SetMaxOpenConns时默认为0，此时SetMaxIdleConns(10)不会panic，但空闲连接实际不可控，依赖驱动和系统限制
db.Ping()根本查不出失效连接
db.Ping()只验证“此刻能建一个新连并执行SELECT 1”，它不碰池里已有的空闲连接。MySQL侧wait_timeout=300断连后，那些连接还静静躺在池里，直到下次被取出执行Query()才暴露invalid connection或i/o timeout。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- k8s readiness probe若只调
db.Ping()，可能误判服务可用 -
SetConnMaxLifetime是唯一缓解手段：它强制连接到期就关，不等DB来杀；推荐设为比数据库wait_timeout小5～10分钟（如MySQL设300s，Go侧设240 * time.Second） -
SetConnMaxLifetime不是保活机制，它不发心跳、不检测连通性，只是计时器一到就关
怎么知道连接池配得对不对
不看db.Stats()就调参，等于闭眼开车。重点关注三个字段的**持续趋势**，不是单次快照值：
立即学习“go语言免费学习笔记（深入）”；
-
WaitCount持续上升 → 连接不够用，优先调高SetMaxOpenConns -
InUse == MaxOpenConns且长期不回落 → 连接借出后没归还，查defer rows.Close()是否漏写、事务是否未commit/rollback -
MaxIdleClosed > 0且频繁增长 → 空闲连接回收太激进，适当提高SetMaxIdleConns或延长SetConnMaxIdleTime
事务内混用db.Query和tx.Query极其危险：前者会从池另取连接，既不参与事务，又额外占坑——事务卡住时，全局池一个连接被绑死，其他请求全在排队等。
