GORM连接池无心跳机制，需用SetConnMaxLifetime（设2～5分钟）强制销毁老化连接防被NAT/防火墙静默断连，并配合SetConnMaxIdleTime被动清理空闲连接，二者须在gorm.Open()后立即通过db.DB()设置。
Go 的 database/sql 连接池本身不支持“心跳探测”
很多人搜“GORM 连接心跳”，其实是想解决连接空闲后被中间设备（NAT、防火墙、云负载均衡）或数据库服务端（如 MySQL 的 wait_timeout）静默断开，导致下次复用时报 read: connection reset by peer 或 invalid connection。但标准库 *sql.DB 没有心跳机制——它只在取连接时做一次 ping（仅限 MySQL 驱动等少数支持的场景），且不主动轮询。
SetConnMaxLifetime 是最接近“心跳”的可控手段
这不是心跳，而是“连接寿命上限”。GORM（实为底层 *sql.DB）会在连接创建后计时，到期即销毁，强制后续请求新建连接。这间接规避了长期存活连接被意外中断的问题。
-
SetConnMaxLifetime应设为略小于数据库的wait_timeout（MySQL 默认 28800 秒 / 8 小时），推荐 2～5 分钟：云环境主备切换快、NAT 超时短，设 2 分钟更稳妥 - 别设成
0（永不过期）或time.Hour（1 小时）：前者易积压 idle in transaction，后者大概率撞上 MySQL 主动 kill - PostgreSQL 用户注意：
pgx驱动支持health_check_period参数，但那是驱动层行为，和*sql.DB无关；GORM 无法透传该参数
真要探测，得自己加 db.Ping() 定时任务
如果业务对连接可用性极度敏感（如金融类长周期批处理），可在初始化后起一个 goroutine，定期调用 db.DB().Ping() 并记录 error。但这不是连接池内置能力，而是应用层兜底：
- 频率别太高（例如 30 秒一次）：频繁
Ping会增加数据库压力，且多数场景没必要 - 必须检查返回 error：仅调用不处理等于没做
- 不能替代
SetConnMaxLifetime：Ping只验证当前连接是否活着，不解决连接老化、事务卡住、连接泄漏等问题
为什么不用 SetConnMaxIdleTime 代替？
SetConnMaxIdleTime 控制空闲连接保留多久后关闭，但它不触发任何探测动作，只是被动清理。它和 SetConnMaxLifetime 是两个维度：
-
SetConnMaxIdleTime：连接空闲超过 X 时间 → 关闭（防资源滞留） -
SetConnMaxLifetime：连接从创建起存活超 Y 时间 → 关闭（防老化失效） - 两者建议都设：例如
SetConnMaxIdleTime(30 * time.Minute)+SetConnMaxLifetime(3 * time.Minute)
真正容易被忽略的是：这两个参数必须在 gorm.Open() 后立刻通过 db.DB() 设置，且 SetConnMaxLifetime 的值必须结合你实际部署环境的网络设备超时策略来定，而不是照搬文档里的“5 分钟”。
