GORM本身不控制TCP Keep-Alive，依赖数据库驱动启用；若底层未显式开启（如MySQL需自定义Dialer调用SetKeepAlive(true)并设SetKeepAlivePeriod），连接池可能长期持有已断连却未探测的“假死连接”，导致查询超时或失败。
默认情况下，GORM 本身不控制底层 net.Conn 的 TCP Keep-Alive 行为，它完全依赖数据库驱动（如 mysql、pgx、sqlserver）所创建的连接是否启用了保活机制。如果你在高并发长连接场景下观察到连接池里堆积大量“假死连接”（ESTABLISHED 但实际对端已断），大概率是底层 TCP 连接没启用或参数太宽松，而不是 GORM 配置的问题。
为什么 GORM 连接池里的连接会卡住不释放
根本原因在于：GORM 使用 database/sql 标准库，而该库只管理连接生命周期（获取、归还、超时），**不主动调用 SetKeepAlive(true) 或设置 TCP_KEEPIDLE 等参数**。一旦底层驱动未显式开启保活，内核就按默认值（tcp_keepalive_time=7200 秒）等待两小时才探测——这意味着连接池可能把一条早已失效的连接当成“可用”反复复用，直到某次 Write() 或 Read() 突然报错（如 broken pipe、connection reset），此时错误才暴露出来。
- 现象典型：服务运行数小时后，
SHOW PROCESSLIST（MySQL）或pg_stat_activity（PostgreSQL）中看到大量空闲连接，但应用层查询开始超时或失败 - 关键误区：以为设置了
SetMaxIdleConns或SetConnMaxLifetime就能解决死连接 —— 它们管的是“连接存活时间”，不是“连接是否还通” - 真实瓶颈：连接池归还连接时不会触发探测；只有真正发起读写时，才会暴露网络异常
MySQL 驱动（go-sql-driver/mysql）如何启用 Keep-Alive
该驱动支持通过 DSN 参数透传底层 socket 设置，无需改代码，直接在连接字符串里加 readTimeout/writeTimeout 不够，必须显式启用保活：
- 在 DSN 中添加
timeout=30s&readTimeout=30s&writeTimeout=30s&interpolateParams=true只控制 SQL 执行超时，不影响 TCP 层 - 真正起作用的是
multiStatements=true&parseTime=true之后追加：&clientFoundRows=true&allowOldPasswords=false—— 这些都不行 - ✅ 正确做法：使用
mysql.ParseDSN+ 自定义Config，并在Config.Net为"tcp"时，在 Dialer 上设置 Keep-Alive - 更简单方案：用
github.com/go-sql-driver/mysqlv1.7+，它会在底层自动调用SetKeepAlive(true)，但**仍沿用系统默认内核参数**（2 小时） - ⚠️ 必须手动干预：通过
mysql.RegisterDialContext注册自定义 dialer，调用tcpConn.SetKeepAlive(true)并设置SetKeepAlivePeriod(30 * time.Second)（Go 1.19+）
PostgreSQL 驱动（pgx/v5）的 Keep-Alive 控制点
pgx 比 MySQL 驱动更透明，它允许你在 pgxpool.Config 的 ConnConfig 中直接配置底层 TCP 行为：
-
ConnConfig.DialFunc是唯一可控入口，必须在这里拿到*net.TCPConn并调用保活设置 - 示例代码片段（Go 1.19+）：
cfg, err := pgxpool.ParseConfig("postgres://user:pass@localhost:5432/db")
if err != nil {
log.Fatal(err)
}
cfg.ConnConfig.DialFunc = func(ctx context.Context, network, addr string) (net.Conn, error) {
conn, err := (&net.Dialer{
KeepAlive: 30 * time.Second, // ⚠️ 注意：这是 Dialer 的 KeepAlive，仅影响新建连接的初始设置
}).DialContext(ctx, network, addr)
if err != nil {
return nil, err
}
if tcpConn, ok := conn.(*net.TCPConn); ok {
tcpConn.SetKeepAlive(true)
tcpConn.SetKeepAlivePeriod(30 * time.Second) // 实际生效的保活周期
}
return conn, nil
}- ⚠️ 常见坑：
Dialer.KeepAlive和SetKeepAlivePeriod不是同一回事 —— 前者只是 Dialer 初始化时的 hint，后者才是真正写入 socket 选项 - 旧版 Go（syscall 或
golang.org/x/sys/unix手动设TCP_KEEPIDLE/TCP_KEEPINTVL/TCP_KEEPCNT - pgx 默认不启用保活；不显式设置，就永远走内核默认 2 小时
验证连接是否真启用了 Keep-Alive
别信日志，抓包看最准。在服务端跑 tcpdump -i any port 5432 or port 3306 -nn -w keepalive.pcap，然后模拟客户端断网（拔网线 / 关机），等 30 秒后看是否有 TCP ACK 探测包发出：
- 成功表现：空闲 30 秒后，出现源端发往目的端的
[ACK]包（无 payload），且目的端无响应 → 后续每 10 秒重发一次（取决于SetKeepAlivePeriod） - 失败表现：全程无任何探测包，只有业务 SQL 的请求/响应包 → 说明保活根本没开，或被驱动忽略
- 注意：Linux
/proc/sys/net/ipv4/tcp_keepalive_*参数只影响未显式设置 socket 选项的连接；一旦代码里调了setsockopt(SO_KEEPALIVE)，这些全局参数就失效了
最易被忽略的一点：GORM 的 *gorm.DB 对象本身不持有连接，所有保活逻辑必须下沉到驱动初始化阶段；你在 GORM 层做任何 Session 或 Callback 设置，对底层 TCP 连接零影响。
