连接池参数必须通过db.DB()设置，不能用gorm.Config；GORM仅封装*sql.DB，所有连接池配置（如SetMaxOpenConns）须调用db.DB()返回实例设置，否则默认无限制或仅2个连接，高并发易超时。
连接池参数必须通过 db.DB() 设置，不是 gorm.Config
GORM 本身不管理连接池，它底层依赖 Go 标准库的 database/sql，所以所有连接池配置都得调用 db.DB() 返回的 *sql.DB 实例来设。直接在 gorm.Config 里写 MaxOpenConns 是无效的。
常见错误是把连接池参数当成 GORM 配置项传进去，结果压测时发现连接数始终卡在默认的 0（无限制）或 2，实际并发一高就超时。
-
db.DB().SetMaxOpenConns(50)：硬性上限，超过会阻塞等待空闲连接，建议设为略高于峰值 QPS（比如峰值 30 QPS，设 50） -
db.DB().SetMaxIdleConns(20)：闲置连接保留在池里的最大数量，太小会导致频繁建连，太大浪费资源 -
db.DB().SetConnMaxLifetime(1 * time.Hour)：强制回收老化连接，避免 PostgreSQL 因 idle_in_transaction_timeout 或网络中间件断连后产生 stale connection -
db.DB().SetConnMaxIdleTime(30 * time.Minute)：比SetConnMaxLifetime更细粒度的空闲回收（Go 1.15+），推荐启用
pgx 驱动下连接池行为和 lib/pq 不同
如果你用的是 github.com/jackc/pgx/v5（强烈推荐），它的连接池是独立实现的，db.DB() 返回的其实是 *sql.DB 包装层，但底层复用 pgx 自己的连接池逻辑。这意味着：
-
SetMaxOpenConns仍生效，但实际连接建立/销毁由 pgx 控制，性能更稳 - 若想用 pgx 原生池（比如需要
BeginTx带 context 超时），得绕过 GORM 直接用pgxpool.Pool，此时db.DB()就没用了 - 别混用：不要同时调用
pgxpool.Connect和gorm.Open(postgres.Open(dsn))，否则双池叠加反而降低效率
而 lib/pq 完全走 database/sql 标准池，行为更“传统”，但缺少对 context 取消、管道化等高级支持。
连接池配置后必须验证是否生效
光设参数不验证，等于没配。PostgreSQL 侧可通过 SELECT * FROM pg_stat_activity WHERE state = 'idle' 查看当前空闲连接数，但更可靠的是在 Go 侧主动检查：
- 启动时打印：
log.Printf("DB pool stats: %+v", db.DB().Stats())，确认MaxOpenConnections、Idle等字段符合预期 - 压测中观察
db.DB().Stats().WaitCount是否持续增长——如果涨得快，说明MaxOpenConns设低了，请求在排队 - 注意
db.DB().Stats().OpenConnections是瞬时值，不是平均值；高峰期抓几次快照比单次更有参考性
漏掉这步，上线后遇到慢查询或连接耗尽，第一反应常是查 SQL 或索引，其实根源只是池子太小。
SSL 模式和连接池生命周期要对齐
本地开发常用 sslmode=disable，但上生产必须切到 sslmode=require 或更严格模式。这个参数影响连接建立成本，进而影响池内连接复用率：
- SSL 握手耗时比非 SSL 高 2–5 倍，如果
ConnMaxLifetime设太短（比如 5 分钟），会导致频繁重握手，吞吐下降 - 若 PostgreSQL 启用了
ssl_renegotiation_limit，连接复用太久可能触发重协商，配合短ConnMaxLifetime会放大开销 - 建议生产环境将
ConnMaxLifetime设为 20–60 分钟，并确保 PostgreSQL 的tcp_keepalives_idle/_interval与之匹配，防止中间网络设备静默断连
很多人调完连接池参数就以为万事大吉，却没意识到 SSL 配置正在悄悄拖慢每次连接复用。
