SetMaxOpenConns=0比设为10更危险，因其语义是“不限制连接数”，高并发下瞬间打满MySQL max_connections（默认151），触发Too many connections错误；而设为10虽限制过严导致请求排队，但至少可控不崩溃。
不配连接池参数，GORM 启动后高并发下必报 Too many connections —— 因为 SetMaxOpenConns 默认是 0（无限制），不是 10 或 20。
为什么 db.SetMaxOpenConns(0) 比设成 10 更危险
Go 的 database/sql 连接池对 MaxOpenConns=0 的语义是「不限制最大打开连接数」，不是「只开 0 个连接」。MySQL 默认 max_connections=151，一旦并发请求稍高（比如压测 QPS > 50），连接数瞬间打满，数据库开始拒绝新连接，错误日志里反复出现 Too many connections。
常见误操作：
- 只传
&gorm.Config{}，没调db.DB().SetMaxOpenConns() - 在 HTTP handler 里每次新建
*gorm.DB，导致每个请求都初始化独立连接池 → fd 耗尽 +database is closed - 用
sync.Once初始化了*gorm.DB，但忘了调db.DB()获取底层*sql.DB去设池参数
必须按顺序设置的三个关键池参数
SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime 必须在应用启动时一次性设好，且有强依赖关系：
- 先调
db.DB().SetMaxOpenConns(100)（生产建议 50–200，视 DB 规格和 QPS 调整） - 再调
db.DB().SetMaxIdleConns(20)—— 注意：这个值不能大于MaxOpenConns，否则 Go 1.12+ 直接 panic，错误信息是"max idle conns exceeds max open conns" - 最后设
db.DB().SetConnMaxLifetime(240 * time.Second)—— 推荐比 MySQL 的wait_timeout小 5～10 分钟（如 MySQL 设 300s，则 Go 侧设 240s），避免连接被 DB 主动断开后还留在池里，下次取出时才报i/o timeout或invalid connection
SetConnMaxIdleTime（Go 1.15+）可选，但非必需；db.Ping() 不能代替 SetConnMaxLifetime，它只检测初始连通性，不清理失效空闲连接。
gorm.Config 和 db.DB() 的职责边界在哪
gorm.Config 只控制 ORM 层行为，比如 SkipDefaultTransaction、Logger、PrepareStmt；它**完全不碰连接池**。所有池参数（MaxOpenConns、MaxIdleConns、ConnMaxLifetime）都必须通过 db.DB() 获取底层 *sql.DB 实例后设置。
典型错误写法：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{
// ❌ 这里设了也没用
// SetMaxOpenConns: 100 ← 编译不过，gorm.Config 没这个字段
})正确写法：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
if err != nil {
log.Fatal(err)
}
sqlDB, err := db.DB()
if err != nil {
log.Fatal(err)
}
sqlDB.SetMaxOpenConns(100)
sqlDB.SetMaxIdleConns(20)
sqlDB.SetConnMaxLifetime(240 * time.Second)生产环境务必关闭 SkipDefaultTransaction
默认情况下 GORM 对单条 Create/Save/Delete 都包一层事务，看似安全，实则放大锁竞争、拖慢响应、浪费连接。生产环境应显式设 SkipDefaultTransaction: true，把事务控制权交还给业务层：
- 简单 CRUD 直接走自动提交，不占事务连接
- 需要一致性时，用
db.Transaction(func(tx *gorm.DB) error { ... })显式包裹，边界清晰 - 该配置不影响
db.Exec()或原生 SQL 执行
最容易被忽略的一点：连接池参数一旦漏设或错序（比如先设 MaxIdleConns 再设 MaxOpenConns），服务可能上线几天才出问题——因为连接泄漏或失效连接堆积是缓慢发生的，监控又常缺池指标，等报警时往往已线上抖动。
