GORM不支持真正嵌套事务，所谓“嵌套”实为SAVEPOINT语法糖；db.Transaction()是一次性闭包模型，无法分段提交或局部回滚，多层调用会导致原子性破裂或静默数据丢失。
直接说结论：GORM 本身不支持真正意义上的嵌套事务，所谓“嵌套”只是保存点（SAVEPOINT）的语法糖；你写的“通用事务组件”如果试图让子函数自主 Commit() 或独立控制事务生命周期，一定会出错——数据可能静默丢失，或触发 current transaction is aborted 这类难以定位的错误。
为什么 db.Transaction() 不能用于嵌套调用场景
db.Transaction() 是一次性闭包模型，内部调用 tx.Begin() 启动事务，回调返回 error 就强制回滚、返回 nil 就提交，之后整个 *gorm.DB 实例失效。它不提供中途挂起、分段提交、局部回滚的能力。
常见误用：
- 在 A 函数里调
db.Transaction()，里面又调 B 函数，B 函数也试图再套一层db.Transaction()—— 第二层其实只是建了个SAVEPOINT，但 B 的 “成功返回” 并不会提交任何东西，A 的闭包结束时才统一决定是否提交 - 把事务逻辑拆到多个函数里，每个都加
db.Transaction()，结果变成多个独立短事务，原子性完全破裂 - 依赖子函数返回
error来“局部回滚”，实际只是让外层整个事务滚掉，无法保留前面已成功的步骤
真正可嵌套的事务组件必须手动管理 *gorm.DB 实例
要支持“调用链中任意环节可设保存点、可局部回滚、外层仍继续”，必须把事务上下文（即 *gorm.DB）显式透传下去，且全程避免使用 db.Transaction()。
实操要点：
- 入口函数用
db.BeginTx(ctx, nil)启动，不是db.Begin()（后者不带 context，无法配合超时控制） - 所有下游函数签名必须接收
tx *gorm.DB参数，禁止内部再调db.开头的方法 - 需要局部容错的地方，调
tx.SavePoint("sp_xxx")，命名按业务语义来，比如"sp_order_create"、"sp_inventory_deduct" - 局部失败时，只调
tx.RollbackTo("sp_xxx")，不要调tx.Commit()或tx.Rollback()—— 那是外层职责 - 外层函数最后统一调
tx.Commit()或tx.Rollback()，且必须确保只调一次
SavePoint 命名和生命周期容易踩的坑
保存点不是“子事务”，它没有独立生命周期，完全依附于外层事务连接。一旦外层提交或回滚，所有保存点立即失效；若外层已因 panic 或 error 回滚过，再操作保存点会直接报错。
高频问题：
- 重复用同一个名字调
tx.SavePoint("sp1")：后一次覆盖前一次，RollbackTo("sp1")会跳过中间状态 - 在 for 循环里动态生成名字但没做唯一性校验，比如
"sp_" + strconv.Itoa(i)，并发下极易冲突 - 全局配置了
DisableNestedTransaction: true，SavePoint()会静默失效，无任何 warning - 混用
tx.SavePoint()和原生tx.Exec("SAVEPOINT sp1")，导致ROLLBACK TO SAVEPOINT找不到目标
一个极简但可用的通用事务组件骨架
下面这个结构不封装 magic，只解决最痛的点：透传 tx、统一错误处理、防止重复 commit/rollback。
func WithTx(ctx context.Context, db *gorm.DB, fn func(tx *gorm.DB) error) error {
tx := db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelDefault})
if tx.Error != nil {
return tx.Error
}
defer func() {
if r := recover(); r != nil {
tx.Rollback()
panic(r)
}
}()
if err := fn(tx); err != nil {
tx.Rollback()
return err
}
return tx.Commit().Error
}
// 使用示例：
err := WithTx(ctx, db, func(tx *gorm.DB) error {
if err := CreateUser(tx, u); err != nil {
return err // 自动回滚
}
if err := CreateProfile(tx, p); err != nil {
tx.RollbackTo("sp_profile_create") // 局部回滚，不影响 user
return nil // 继续执行后续逻辑
}
return nil
})
关键细节在于：组件只管启停，不碰保存点；保存点的设与回滚全由业务函数自己决定——这反而更可控。很多人想把“设点→操作→异常判断→回滚”打包成一个装饰器，但业务语义千差万别，硬封装只会让错误路径更难 debug。
