事务提交后触发Hooks是最终一致性的核心落点，GORM 1.20+将after_* Hooks绑定到事务生命周期，确保仅在提交成功后执行；本地消息表+定时扫描为兜底保障；SavePoint配合补偿Hook处理部分失败；需防控超时与连接泄漏。
事务提交后触发 Hooks 是最终一致性的核心落点
事务本身只管数据库内多张表的原子性，但事件驱动系统里往往要联动 Redis、MQ、外部 HTTP 服务等。GORM 的 after_create、after_update 等 Hooks 不在事务内执行，所以天然适合做“事务成功后再异步发消息”这件事。关键在于：必须确保这些 Hooks 只在事务真正提交后才触发，不能在回滚时误发。
GORM 1.20+ 默认已将 Hooks 绑定到事务生命周期——比如你在 db.Transaction() 闭包里调用 Create()，其注册的 after_create 回调会在事务提交成功后才执行；若事务中途返回错误或 panic，Hooks 根本不会触发。这是靠 GORM 内部的 CommitOrRollbackTransaction 回调链实现的，不用手动判断事务状态。
- 别在 Hooks 里做阻塞操作（比如同步 HTTP 调用），否则会拖慢主请求响应
- 不要在
before_*Hooks 里修改数据并期望被事务保护——它们发生在事务开始前或中间，不参与回滚 - 如果用了自定义 Hook 函数（如
func(*gorm.DB) error），需确认它是否注册在事务安全的回调点上（优先选after_*）
本地消息表 + 定时扫描是兜底保障的关键手段
光靠 Hooks 发消息不够可靠：进程 crash、MQ 不可用、网络抖动都可能导致事件丢失。生产环境必须引入本地消息表（Local Message Table），把“要发什么消息”先写进 MySQL 同一事务里，再由独立消费者拉取投递。
典型结构：messages 表含 id、topic、payload、status（pending/sent/failed）、created_at。在订单创建事务中，用 tx.Create(&Message{...}) 一起写入：
err := db.Transaction(func(tx *gorm.DB) error {
if err := tx.Create(&Order{...}).Error; err != nil {
return err
}
// 同一事务内写本地消息
if err := tx.Create(&Message{
Topic: "order.created",
Payload: `{"order_id": 123}`,
Status: "pending",
}).Error; err != nil {
return err
}
return nil
})
- 消息表必须和业务表在同一数据库、同一事务中，否则无法保证原子性
- 定时任务扫描
status = 'pending'的记录，失败后更新为failed并告警，避免无限重试压垮 MQ - 不要依赖 Hooks 自动写消息表——Hooks 可能被跳过（如用原生 SQL 操作绕过 GORM），必须显式写入
GORM SavePoint 配合补偿 Hook 处理部分失败场景
有些业务需要“主流程成功，但某些外围动作失败后自动补偿”，比如扣库存成功、发短信失败。这时不能简单回滚整个事务，而要用 SavePoint 切分边界，再在补偿 Hook 中反向操作。
例如：先在事务中扣减库存并设保存点，再尝试发短信；失败则回滚到该保存点，再调用 after_rollback_to_stock Hook 补回库存：
err := db.Transaction(func(tx *gorm.DB) error {
// 扣库存（主操作）
if err := tx.Model(&Inventory{}).Where("id = ?", gid).
Update("stock", gorm.Expr("stock - 1")).Error; err != nil {
return err
}
<pre class="brush:php;toolbar:false;">// 设保存点
sp := tx.SavePoint("before_sms")
// 尝试发短信（可能失败）
if err := sendSMS(); err != nil {
tx.RollbackTo(sp) // 回滚到保存点，库存扣减被撤销
return err
}
return nil
})
-
SavePoint不是嵌套事务，它只是事务内的一个标记位置，性能开销远小于Begin()新事务 - 补偿逻辑不能写在
defer或普通函数里，必须通过 GORM Hook（如自定义after_rollback_to_*）绑定，确保只有真实回滚时才触发 - Redis 预扣库存这类跨库操作，必须配套 Lua 脚本实现原子回补，不能靠应用层两次请求
事务超时与连接泄漏是最终一致性最容易被忽略的断点
很多线上事故不是逻辑错，而是事务没及时释放：HTTP 请求超时了，但 db.Transaction() 闭包还没执行完，连接卡在池子里，后续请求全被堵住。更糟的是，此时 Hooks 还没触发，消息永远发不出去。
GORM 本身不管理事务超时，得靠外层控制：
- 给
db.Transaction()传入带 context 的变体：db.WithContext(ctx).Transaction(...)，并在 HTTP handler 中设置ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second) - 手动事务（
Begin()）必须配defer+recover()+Rollback()，否则 panic 会导致连接永久泄漏 - 监控指标一定要接入：
gorm_sql_tx_duration_seconds（耗时）、gorm_sql_tx_errors_total（失败率）、database_sql_conn_max_open_connections（连接池使用率）
最终一致性不是“放任失败”，而是把失败变成可观测、可追踪、可补偿的状态。事务是底线，Hooks 是延伸，本地消息表是保险绳——三者缺一不可，且任何一环的超时或泄漏都会让整条链路失效。
