GORM不控制单次连接生命周期，实际由database/sql的SetConnMaxLifetime（控制归还后最大存活时长）、SetConnMaxIdleTime（控制空闲超时）和连接池参数共同管理。
GORM 本身不控制单次数据库连接的生命周期，它复用 database/sql 的连接池机制；所谓“限制单次连接生命周期”，实际是配置底层 *sql.DB 的空闲/存活时长参数。
为什么不能直接设置“单次连接活多久”
GORM 的 *gorm.DB 是一个高层封装，它不持有具体连接，只管理连接池。真正建立、复用、回收 TCP 连接的是其内部的 *sql.DB 实例。GORM 没有提供类似 SetConnLifetime() 的接口 —— 这个能力由 database/sql 提供，且仅作用于“空闲连接”（idle），而非“已取出正在使用的连接”。
SetConnMaxLifetime 是最接近你要的效果
这个方法控制的是：**从连接池中取出后、尚未被关闭的连接，最多能存活多久**。超过该时限，下次被取用前会被主动关闭并新建连接。
- 它不强制中断正在执行 SQL 的连接，只影响“归还到池中后待命”的连接
- 适用于防止连接因网络中间件（如 NAT 超时、LB 断连）僵死
- 值设得太短（如 30s）会导致频繁建连，增加 handshake 开销
- 值设得太长（如 24h）可能让已失效连接滞留池中，后续报
read: connection reset by peer
使用方式（必须在 gorm.Open 后立刻获取底层 *sql.DB）：
db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{})
if err != nil {
panic(err)
}
sqlDB, err := db.DB()
if err != nil {
panic(err)
}
sqlDB.SetConnMaxLifetime(1 * time.Hour) // 推荐 30m ~ 2h
SetMaxIdleConns 和 SetMaxOpenConns 间接影响连接复用频率
这两个参数不控制单个连接寿命，但决定连接是否容易被复用或淘汰：
-
SetMaxIdleConns(5)：池中最多保留 5 个空闲连接；超出部分会立即关闭，变相缩短了“空闲状态下的存活时间” -
SetMaxOpenConns(20)：限制总连接数上限；当并发请求多于该值，新请求需等待空闲连接释放，间接延长了连接被复用的周期 - PostgreSQL 场景下，
SetMaxOpenConns建议 ≤ 50（参考：每个连接约占用 10MB 内存，避免 DB OOM）
真正需要“短连接语义”时，别用 GORM 连接池
如果你的场景明确要求每次操作都建新连、用完即断（例如 CLI 工具、短时批处理、高隔离性调试），就不要依赖 GORM 的全局 *gorm.DB：
- 每次操作前调用
gorm.Open(...)，用完立刻调用db.Close() - 注意：
gorm.Open是重量级操作，性能差、易泄漏，仅限低频、非服务型场景 - 更合理的方式是：用
sql.Open+sql.Conn直接控制单次连接，绕过 GORM
连接池不是万能的，强行用它模拟短连接，只会让问题更隐蔽 —— 比如你以为关了 GORM 实例就断了连接，其实底层 *sql.DB 还在默默维持着一堆 idle 连接。
