默认MaxOpenConns=0在容器中极危险：它导致连接数无上限，易触发Too many connections或too many open files；容器重启后旧连接残留引发database is closed；必须显式调db.DB().SetMaxOpenConns才能生效。
容器环境里 GORM 连接池默认值为什么危险
默认 MaxOpenConns=0 在容器中等于放任连接数无上限，K8s 里一个 Pod 的 fd 限制通常只有 1024 或 65536，一旦并发请求稍高（比如压测或突发流量），Too many connections 或 too many open files 就直接炸。更隐蔽的是：容器重启后连接池没重建，旧连接残留导致 database is closed 频发。
GORM 初始化时必须调 db.DB().SetMaxOpenConns 才生效
GORM 的 gorm.Open 返回的是 *gorm.DB，它只是个封装层，真正管连接池的是底层的 *sql.DB。不显式调 db.DB().SetMaxOpenConns(25)，就永远用不到你设的值。
- 先设
SetMaxOpenConns，再设SetMaxIdleConns，且后者不能大于前者，否则运行时 panic 报错："max idle conns exceeds max open conns" - 容器内存受限时，
PostgresMaxIdleConns=10比默认 2 是更稳妥的选择——空闲连接少，但够冷启动用 -
SetConnMaxLifetime必须设，推荐240 * time.Second（比 PG 的wait_timeout=300小 60 秒），避免连接被数据库静默断开后还躺在池里
多实例部署下，每个 Pod 必须独立配池，不能共享 DB 实例
常见错误是把 *gorm.DB 当全局单例塞进 config 包、或在 handler 里每次 new 一个 db——前者导致所有 Pod 共用同一套连接参数（实际是不同底层 *sql.DB，但配置混乱），后者造成 fd 泄漏。
- 正确做法：在
main()启动阶段初始化一次*gorm.DB，通过依赖注入传给 service 层 - 若用了读写分离，主库和从库必须是两个独立
*sql.DB实例，各自调自己的SetMaxOpenConns；共用一个实例会导致从库连接挤占主库资源 - K8s readiness probe 别只调
db.Ping()，它不验证池中连接有效性；建议加一层轻量查询如db.Raw("SELECT 1").Scan(&i)
横向扩缩容时连接池参数要按 Pod 数反向缩放
比如你数据库总连接上限是 1000，预估最多跑 20 个 Pod，那每个 Pod 的 MaxOpenConns 就不该超过 50（1000 ÷ 20）。硬写死 100，在扩到 15 个 Pod 时就超限了。
- 用环境变量传参，比如
DB_MAX_OPEN_CONNS=40，启动时读取并校验是否 ≤ 数据库侧总配额 - 注意
MaxIdleConns不是越大越好：idle 连接占内存，容器内存紧张时反而触发 OOMKilled - PostgreSQL 的
max_connections默认常是 100，别忘了在 RDS 或自建 PG 里同步调大，否则 Go 侧再怎么调也连不上
容器里最易忽略的一点：连接池参数不是“设完就稳”，它必须和 K8s 的 liveness/readiness 探针、数据库的超时策略、以及业务请求的平均耗时形成闭环。比如 ConnMaxLifetime=240s，但你的服务平均请求耗时 3s，那每分钟约有 2% 的连接会在归还前过期——这个损耗得在压测中看真实毛刺。
