db.Transaction 是并发事务的默认安全入口，它自动管理连接、panic捕获与回滚、连接归还，适配高并发；手动调用 db.Begin() 易因遗漏 Commit/Rollback 导致连接池耗尽；事务内必须统一使用 tx 而非全局 db，避免脏读/幻读；AfterCommit 钩子需谨慎异步化且不可共享状态；嵌套事务实为 Savepoint，不能替代行锁或乐观锁。
db.Transaction 是并发事务的默认安全入口
绝大多数业务场景下，并发写操作必须走 db.Transaction，而不是手写 db.Begin()。它内部自动管理连接获取、panic 捕获与回滚、连接归还，天然适配高并发请求压测下的连接池复用。若自己调 db.Begin() 后又忘了 tx.Commit() 或 tx.Rollback()，连接会卡在事务中，很快触发 acquire connection timeout，整个服务吞吐骤降。
实操建议：
- 所有涉及多表变更、状态流转（如订单创建+库存扣减）的 handler，一律包裹在
db.Transaction闭包里 - 闭包函数必须显式返回
error类型；db.Transaction仅在函数返回非 nil error 时回滚，不校验逻辑分支是否遗漏return - 不要在闭包里直接
return（无值），否则事务静默丢弃；推荐用命名返回值或统一出口
混用 db 和 tx 导致并发数据不一致
常见错误现象：事务内一部分操作用 tx.Create()，另一部分误用全局 db.Create()，结果后者直连数据库并立即落库，而前者还在事务上下文中。当并发请求同时执行，就会出现“库存已扣但订单未建”或“A 用户看到 B 用户未提交的数据”等脏读/幻读问题。
根本原因是：db.Begin() 返回的是全新 *gorm.DB 实例，带事务上下文；原始 db 对象仍是无事务的普通连接句柄。两者完全隔离。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 事务闭包内所有 CRUD 必须使用传入的
tx变量，禁止出现任何db.Xxx() - IDE 中可配置检查规则：禁止在
func(tx *gorm.DB) error参数签名函数体内引用未声明的db - 若需跨函数传递事务上下文，应显式传参
tx，而非依赖全局变量或 context.WithValue
AfterCommit 钩子在并发场景下容易失效
tx.AfterCommit() 常被用来触发缓存更新、HTTP 通知等 I/O 操作，但它只绑定当前 tx 实例生命周期。在并发请求中，若事务函数内新建了另一个 *gorm.DB（比如调 tx.Session() 或 tx.WithContext()），钩子就不再生效——因为新实例不是原 tx，也不会继承钩子注册。
更危险的是：多个 goroutine 并发注册 AfterCommit，它们按注册顺序执行，但彼此无同步机制，若钩子里有共享状态（如 map 写入），可能引发 panic。
实操建议：
- 钩子注册必须紧接在
db.Transaction闭包开头，且只对参数tx调用一次tx.AfterCommit() - 钩子函数内禁止阻塞操作；HTTP 请求、日志上报等必须异步化，例如发消息到 channel 交由 worker 处理
- 避免在钩子里修改闭包外变量；如需收集结果，用
sync.Map或原子操作
嵌套事务本质是 Savepoint，不是真正并发隔离
GORM 不支持跨 goroutine 的事务共享，所谓“嵌套事务”只是通过 tx.SavePoint("sp") 和 tx.RollbackTo("sp") 模拟的保存点。MySQL/PostgreSQL 底层行为一致：外层事务回滚会清除所有 savepoint，内层 rollbackTo 不影响外层已执行语句。
这意味着：它无法解决真正的并发冲突问题，比如两个请求同时尝试扣同一商品库存。Savepoint 只能局部回滚，不能替代行锁或乐观锁。
实操建议：
- 需要并发控制时，优先用
SELECT ... FOR UPDATE加行锁，或在模型字段加 version 字段做乐观锁 - Savepoint 仅用于单请求内“部分失败可恢复”的逻辑，如：主流程成功但附件上传失败，允许回退附件操作而不影响主体
- 避免在 savepoint 内再调
tx.Begin()，GORM 会报invalid transaction；要用就统一用tx.SavePoint()系列 API
tx 生命周期、db 引用范围、钩子绑定关系，三者稍一错位，并发时的数据异常就很难复现和定位。 
