Broken pipe 是因 MySQL 主动关闭连接而 GORM 连接池未探活所致；需启用 pre-ping、设置 SetConnMaxLifetime

Broken pipe 在 GORM 里不是连接池坏了，而是连接已经死了你还用它——必须让连接池自己先探活，而不是靠猜。

为什么 GORM 会报 write: broken pipe？

错误发生在你调用 db.Create()、db.First() 或事务提交时，GORM 尝试往一个已被 MySQL 主动关闭的 socket 上写数据。MySQL 默认 wait_timeout=28800（8 小时），超时后直接 kill 连接；但 GORM 的连接池没感知，下次借出这个“僵尸连接”，一写就崩。

• 这不是网络抖动，也不是 GORM 配置错，是连接生命周期和数据库服务端策略不匹配
• 日志里如果固定在某个整点（比如每天凌晨 2 点）密集出现，基本可锁定为 wait_timeout 触发
• db.Exec("SELECT 1") 手动测试能通 ≠ 连接池里所有连接都活——池子里可能混着几十个已失效句柄

GORM 连接池必须显式启用 pre-ping

GORM 底层用 database/sql，但默认不开启连接有效性验证。必须在 gorm.Open() 时传入 gorm.Config{PrepareStmt: true} 并配置底层 *sql.DB 的连接池参数：

pipe

深入设计 GitHub Actions 工作流——涵盖触发策略、安全加固、性能优化、PR 自动化和可重用工作流设计。当需要新的 GHA 工作流设计或高级优化时使

下载

db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{
  PrepareStmt: true,
})
sqlDB, _ := db.DB()
sqlDB.SetConnMaxLifetime(55 * time.Minute)        // 必须 < wait_timeout
sqlDB.SetMaxOpenConns(100)
sqlDB.SetMaxIdleConns(20)
sqlDB.SetConnMaxIdleTime(30 * time.Minute)

关键一步：启用 pre-ping，让每次从池中取连接前自动执行 SELECT 1：

• 新版 GORM（v1.25+）推荐用 mysql.New() 构造器传参：mysql.New(mysql.Config{DSN: dsn, DefaultStringSize: 256})，再配合 &gorm.Config{SkipDefaultTransaction: true}
• 更稳妥的是直接操作 *sql.DB：在 sqlDB 初始化后加 sqlDB.Ping() 测试连通性，并确保 SetConnMaxLifetime 比 MySQL 的 wait_timeout 少至少 60 秒
• 别依赖 SetConnMaxIdleTime 单独生效——它只管空闲连接，不防活跃连接中途断开

TCP 层保活对 GORM 无效，但对长连接服务端很重要

GORM 是客户端角色，它不监听 TCP 连接，所以 SO_KEEPALIVE、TCP_KEEPIDLE 这类设置对 GORM 本身无意义。这些参数只影响服务端（如 Gin 启动的 HTTP 服务）或直连 Redis/MySQL 的 net.Conn 场景。

• 如果你用 GORM 做服务端 API 的数据访问层，那真正的保活责任在 HTTP Server（比如 Gin 的 http.Server），不是 GORM
• 但如果你用 GORM 直连数据库且走长连接（如嵌入式场景），需确认 MySQL 客户端驱动是否支持 tcpKeepAlive 参数（部分 fork 版本支持，官方 mysql-go-driver 不暴露）
• 真正要配 TCP keepalive 的地方是：反向代理（Nginx）、云负载均衡（CLB/ALB）、以及你的 Go HTTP 服务启动代码里的 net.ListenConfig

最容易被忽略的是：GORM 的 pre-ping 不是免费的——每次查询前多一次 round-trip，QPS 高时延迟微增，但它换来的是确定性。比起半夜被 Broken pipe 报警叫醒重连，这点代价值得。