最稳妥方式是在BeforeEach开启事务、AfterEach回滚，确保所有DB操作共用同一Orm实例且不提交；需检查o.Tx非nil再回滚，避免panic，并显式传递事务给Raw查询。
Beego 单元测试里怎么让数据库操作自动回滚
测试中写入的数据不能留到下一次跑，最稳妥的方式是每个测试用例执行完立刻回滚事务，而不是清空表或删库。Beego 原生不提供「测试专用事务隔离」机制，得靠手动控制 orm.NewOrm() 的事务生命周期来实现。
关键点在于：测试期间所有 DB 操作必须走同一个 Orm 实例，并在 BeforeEach 开启事务、AfterEach 回滚，且不能调用 Commit()。
- 务必在
BeforeSuite完成beego.TestBeegoInit()和 ORM 初始化（如orm.RegisterDataBase()），否则NewOrm()会 panic -
o.Begin()必须在BeforeEach中调用，不能放在测试函数内部——否则可能漏掉某些前置插入（比如控制器初始化时的默认数据） - 回滚前要检查事务是否已提交或已关闭，避免调
o.Rollback()时报sql.ErrTxDone；可加一层判断：if o.Tx != nil { o.Rollback() } - 不要依赖
defer o.Rollback()，因为defer在函数返回时才执行，而 Beego 测试是并发运行多个It块，defer会绑定到错误的作用域
为什么用事务回滚比 truncate 表更可靠
直接 TRUNCATE TABLE 或 DELETE FROM 看似简单，但在 Beego 测试中容易出问题：外键约束报错、自增 ID 重置影响后续逻辑、并发测试时表被锁、或者忘记清理某张关联表。
事务回滚天然具备原子性，不管中间插了多少条记录、改了多少字段、触发了多少钩子（如 PreInsert），只要没 Commit，整个上下文就干净退出。
- 事务回滚不影响数据库连接池状态，也不触发 DDL 操作，速度远快于
TRUNCATE - 能覆盖软删除字段（如
is_deleted）的误置场景，而DELETE可能漏掉这类逻辑 - 如果 ORM 层用了
QuerySeter或原生Raw查询，它们默认不参与当前事务——必须显式传入o.Raw().SetOrm(o)才能被回滚捕获
Ginkgo 测试中事务回滚的典型结构
用 Ginkgo 组织测试时，事务控制要嵌套在 BeforeEach/AfterEach 里，而不是每个 It 块里单独写。下面是一个可复用的骨架：
var o orm.Ormer
var txErr error
BeforeEach(func() {
o = orm.NewOrm()
txErr = o.Begin()
if txErr != nil {
Fail("failed to begin transaction: " + txErr.Error())
}
})
AfterEach(func() {
if txErr == nil && o.Tx != nil {
o.Rollback()
}
})
注意：o.Tx != nil 是必要判断，因为 Begin() 失败时 o.Tx 为 nil，此时调 Rollback() 会 panic。
- 所有测试数据插入都必须用这个
o实例，不能在测试里再调orm.NewOrm()，否则事务不共享 - 如果控制器方法内部自己 new 了一个
Orm，那它的操作不会被当前事务捕获——这时得用依赖注入或 mock 替换 ORM 实例 - Beego 的
TestBeegoInit()默认启用 ORM，但不会自动开启事务，这一步必须手动补全
容易被忽略的 GORM 替换场景
如果你已在项目中用 GORM 替代了 beego/orm，那上面整套基于 Orm 的事务回滚就失效了。GORM 的事务是通过 db.Transaction() 闭包管理的，没法像 beego orm 那样全局 hold 住一个事务对象。
此时推荐做法是：在测试初始化阶段，用 db.Session(&gorm.Session{AllowGlobalUpdate: true}) 创建一个带事务的 session，再把它注入到 controller 或 service 层；或者干脆在每个测试里用 db.Transaction(func(tx *gorm.DB) error { ... }) 包裹业务逻辑，确保回滚由闭包自动完成。
最麻烦的是混合使用：部分模块走 beego orm、部分走 GORM。这种情况下，事务无法跨 ORM 实例传播，只能拆成独立测试用例，或统一迁移到 GORM。
