GORM v2 无事务级钩子，BeforeBegin等不存在；唯一原生支持的是tx.AfterCommit()，须在tx.Begin()后立即注册且不可替换tx实例；模型After*钩子返回error被忽略，不触发回滚。
事务钩子根本不存在，别在 Callbacks 里找 BeforeBegin
GORM v2 没有 BeforeBegin、AfterCommit 或 AfterRollback 这类事务级钩子——它的 Callbacks 系统只覆盖模型操作（Create、Update、Delete、Save），对 db.Begin()、tx.Commit() 这些事务控制方法完全不监听。你注册了也白注册，不会触发。
常见错误是翻文档看到“Callback”就以为能 hook 事务生命周期，结果加了一堆 db.Callback().Transaction().Before(...)，运行时零日志、零报错、零执行。
- 真要响应事务开始/提交/回滚，必须自己封装入口函数，比如
WithTx(fn func(*gorm.DB) error) error - 或者用
tx.AfterCommit()（注意：这是*gorm.DB方法，不是全局 callback） - 别试图给
db.Begin()打补丁——它返回的是新*gorm.DB实例，GORM 不会在其上自动注入任何回调链
tx.AfterCommit() 怎么写才真正生效
tx.AfterCommit() 是 GORM v2 提供的唯一原生事务后钩子，但它极易失效：只绑定到当前 tx 实例，且仅在 tx.Commit() 成功后调用一次。
典型失效场景：你在 db.Transaction() 函数体外注册 tx.AfterCommit()，或在事务内又调用 tx.Session(...) 创建新实例，钩子就断了。
- 必须在
tx := db.Begin()后**立即**注册：tx.AfterCommit(func() { log.Println("committed") }) - 注册后不能再用
tx.Session()或tx.WithContext()替换tx，否则新实例不继承钩子 - 多个
AfterCommit按注册顺序执行，但无事务原子性——其中一个 panic 不影响其他执行，也不导致回滚 - 钩子里禁止阻塞操作（如 HTTP 请求），否则拖慢整个事务提交；建议发消息到 channel 或写本地日志
事务中模型钩子（BeforeCreate 等）的坑在哪
模型钩子（如 BeforeCreate）在事务中照常执行，但行为和单条操作不同：它们共享同一事务上下文，但时机不可控，尤其容易误判“数据是否已落库”。
例如你在 AfterCreate 里调用外部 API，API 失败了，但 GORM 不会因此回滚事务——After* 钩子返回 error 被忽略，事务照常提交。
-
Before*钩子返回error会中断当前操作并回滚事务（如果已在事务中） -
After*钩子返回error**完全被忽略**，既不重试也不回滚，静默丢弃 - 想确保“操作已持久化且事务已提交”，不能依赖任何内置钩子，得在
tx.Commit()成功后手动触发后续动作 - 在钩子里执行
tx.Create()或tx.Model().Update()属于高危操作，可能引发死锁或字段覆盖
如何安全地复用事务逻辑而不污染模型
很多人把事务相关逻辑（如打日志、设 trace_id、发消息）硬塞进 BeforeCreate，结果跨模型复用时只能复制粘贴，或靠结构体嵌入——但嵌入同名钩子会被覆盖，且无编译提示。
正确做法是剥离事务感知逻辑，让模型钩子只做“该模型该做的事”，事务上下文由外部注入。
- 用
context.WithValue()在db.Begin()前注入标识，如ctx := context.WithValue(context.Background(), txKey, true) - 在
BeforeCreate里检查tx.Statement.Context.Value(txKey)，有值再执行事务专属逻辑 - 共用函数提取为普通函数（如
logTxStart(tx *gorm.DB)），而非嵌入结构体的钩子方法 - 避免在钩子里访问
tx.Statement.Dest后直接类型断言——软删除时它可能是*User，也可能是User，取决于调用方式
AfterCommit 做最终一致性的逻辑，都得自己 handle Commit() 的返回值和重试；所有想在事务提交后发通知的代码，都不能放在模型钩子里——那只是个幻觉。 
