应优先使用db.transaction而非db.begin()，因其自动处理panic回滚、成功提交及连接归还；手动begin易漏commit/rollback致连接卡死或数据部分落库，且混用全局db会破坏事务原子性。
事务本身不能“迁移”，所谓平滑切换，本质是把旧事务逻辑从裸写 SQL 或手写 db.Begin()/tx.Commit() 模式，安全、可观察地过渡到 GORM 的 db.Transaction() 或 tx.Create() 链式调用上，同时保证并发一致性不被破坏。
为什么直接套用 db.Transaction() 会出错
很多人一上来就用 db.Transaction(func(tx *gorm.DB) error { ... }) 包住原有逻辑，结果发现事务不生效、锁表、甚至死锁。根本原因不是函数用错了，而是 GORM 事务默认不共享连接上下文：
- 旧代码里
tx := db.Begin()后，所有tx.Create()、tx.First()都明确走同一个*gorm.DB实例；GORM 的Transaction回调里传入的tx是新生成的会话，但如果你在回调里又调用了外部未传入tx的服务方法（比如userService.GetByID(id)），它内部仍用的是原始db，这就变成两个独立事务了 - 嵌套调用时，GORM 不自动传播事务上下文 —— 它不像 Spring 的
@Transactional那样靠 ThreadLocal 或 context.Value 自动透传 - 日志里看到
COMMIT成功，但数据库查不到数据？很可能是你忘了在回调函数末尾return nil，GORM 把非 nil error 当作 rollback 触发点，而你返回了fmt.Errorf("xxx")却没意识到它已被捕获并 rollback
如何让老事务逻辑“无感”接入 GORM 事务
核心思路：不改业务层调用方式，只改底层 DAO 层的数据访问入口，让它们支持接收可选的 *gorm.DB 参数。这样上层能继续用 userService.CreateOrder(...)，而事务内调用时自动注入 tx：
- DAO 方法签名统一改成带
db *gorm.DB参数，例如：func (u *UserDAO) Create(db *gorm.DB, user *User) error，内部所有db.Create()都用传入的db，而不是硬编码的全局db - 旧事务块里，把
db.Begin()替换为db.Transaction()，并在回调中显式把tx传给所有 DAO 方法，例如：userDAO.Create(tx, &u)、orderDAO.Create(tx, &o) - 如果某些 DAO 调用链很深（比如 A→B→C），不要层层透传
tx，改用context.WithValue(ctx, txKey, tx)注入，并在 DAO 内部从ctx取；但注意：GORM 本身不读这个 context，你得自己封装一层GetDBFromCtx(ctx) - 别依赖
db.Session(&gorm.Session{...})做事务伪装 —— Session 只控制 PreparedStmt、DryRun 等行为，不提供事务隔离能力
SavePoint 不是银弹，慎用于跨服务边界
有些团队想用 tx.SavePoint("sp1") + tx.RollbackTo("sp1") 来模拟“局部回滚”，结果发现外层事务依然失败。问题出在两点：
- SavePoint 只对当前
*gorm.DB实例有效，如果你在 SavePoint 后调用了另一个服务的 DAO（它用了自己的db），那个 DAO 的操作完全不受该 SavePoint 控制 - MySQL 的 SavePoint 在事务提交前才真正生效，而 GORM 的
RollbackTo是客户端模拟 —— 它只是记下位置，后续操作仍可能因约束冲突提前失败，最终整个事务还是 rollback - PostgreSQL 对 SavePoint 支持更严格，但一旦触发
ROLLBACK TO SAVEPOINT，其后所有语句必须在同一个事务块内完成，否则报ERROR: no such savepoint - 真正需要局部容错的场景（如发消息失败不影响主流程），应该用最终一致性 + 补偿事务，而不是在 DB 层强压 SavePoint
上线前必须验证的三个点
平滑切换最怕“看着正常，线上崩盘”。以下三点不验证完，别上生产：
- 并发压测时检查锁等待：启动
SHOW ENGINE INNODB STATUS，确认没有lock wait timeout或大量waiting for table metadata lock—— 这往往说明你用了AutoMigrate或CREATE INDEX类 DDL 操作混在事务里 - 查日志确认事务粒度：GORM 默认开启
logger.Default.LogMode(logger.Info)后，每个BEGIN/COMMIT/ROLLBACK都应有对应 SQL 日志；如果只有INSERT没有BEGIN，说明事务没包住 - 手动 kill 进程测试 rollback：在事务中间加
os.Exit(1)，看数据库是否干净回滚；特别注意外键级联和触发器行为，GORM 不控制这些，得靠数据库自身事务机制兜底
事务切换最难的从来不是语法，而是把原来散落在各处的 db.Query、tx.Exec、rows.Scan 全部收口到统一的 DAO 接口里——这步做完，GORM 事务才能真正落地。否则永远在 patch 和 workaround 之间打转。
