客户端断开时GORM事务不会自动回滚，必须通过context.WithTimeout绑定请求生命周期、defer兜底回滚、Body读取探测断连，并配合数据库空闲事务超时机制（如PostgreSQL的idle_in_transaction_session_timeout）共同防御孤儿事务。
客户端断开时事务不会自动回滚，必须主动干预
GORM 本身不感知 HTTP 连接状态，db.Transaction() 或 tx := db.Begin() 开启的事务，一旦客户端在请求中途关闭连接（如浏览器刷新、超时断开、移动端切后台），Go HTTP handler 可能还在执行 SQL，但后续 Commit() 或 Rollback() 永远不会被调用 —— 这就留下一个“孤儿事务”，占用数据库连接、锁住行或表，严重时拖垮整个库。
用 context.WithTimeout + defer tx.Rollback() 是基础防线
不能只靠 tx.Commit() 成功才结束；必须确保任何退出路径（包括 panic、return、context cancel）都触发回滚。关键点是：把事务绑定到请求上下文，并用 defer 做兜底。
- 在 handler 中传入带超时的
ctx，比如ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second) - 用
db.WithContext(ctx).Transaction(...)或tx := db.WithContext(ctx).Begin()，让底层驱动能响应 cancel - 手动开启事务时，必须紧跟
defer func() { if tx != nil { tx.Rollback() } }()，且该 defer 要在所有可能 return 之前注册 - 注意：如果事务内用了
go func() {...}()启动 goroutine，它会脱离当前ctx生命周期，必须显式传递并检查ctx.Done()
检测客户端断开：读取 http.Request.Body 会提前失败
Go 的 http.Request 本身不暴露“连接是否已断”接口，但有个可靠副作用：尝试读取 r.Body（哪怕只读 1 字节）会在客户端断开时立即返回 io.ErrUnexpectedEOF 或 io.EOF。这对长事务尤其有用。
- 在事务开始前，加一次轻量探测：
_, err := r.Body.Read(make([]byte, 1)) - 若
err != nil && errors.Is(err, io.EOF) || errors.Is(err, io.ErrUnexpectedEOF)，说明客户端已走，直接返回 HTTP 499（Client Closed Request），不进事务 - 这个技巧不能替代 context 超时，但能早 100–500ms 截断无效请求，减少孤儿事务发生概率
生产环境必须配数据库层超时与 kill 杀手锏
Go 层再严谨，也防不住网络闪断、LB 中间件悄悄断连等场景。PostgreSQL 和 MySQL 都提供会话级空闲超时机制，这是最后一道保险。
- PostgreSQL：启动时设置
idle_in_transaction_session_timeout = 30000（单位 ms），超时后自动ROLLBACK并断开连接 - MySQL：设
wait_timeout和interactive_timeout（建议 60–120 秒），配合应用层sqlDB.SetConnMaxIdleTime(45 * time.Second) - 定期清理残留：可写一个 cron job，查
pg_stat_activity中state = 'idle in transaction'且now() - backend_start > interval '60 seconds'的会话，调用pg_terminate_backend(pid)
真正难处理的不是“怎么关”，而是“关得太晚”。事务生命周期必须和请求生命周期对齐，而对齐的关键不在 ORM 封装，而在你是否把 context、defer、数据库配置这三块钉死。
