buffalo框架默认不自动管理事务，需显式调用begintx()开启、commit()提交或rollback()回滚；混用beego orm会导致事务隔离，嵌套事务和savepoint不支持。
Buffalo 框架默认不自动管理事务
Buffalo 本身不封装事务生命周期，buffalo.DB 返回的是底层 sqlx.DB 或 gorm.DB（取决于你配置的 ORM），事务必须显式开启、提交或回滚。如果你直接调用 buffalo.DB.Create() 或 buffalo.DB.Update()，这些操作都在自动提交模式下运行，无法回滚——哪怕后续代码 panic 了也不会触发回滚。
使用 tx := buffalo.DB.BeginTx() 手动控制事务
Buffalo 推荐方式是通过 buffalo.DB.BeginTx() 获取事务对象，再在该事务上执行所有数据库操作。注意它接受一个 context.Context 和可选的 *sql.TxOptions：
-
tx是*sqlx.Tx类型（非*gorm.DB），所有查询/更新都需调用tx.Queryx()、tx.NamedExec()等方法 - 不能混用
buffalo.DB和tx：一旦用了事务，就必须全程用tx对象，否则操作不在同一事务上下文中 - 必须显式调用
tx.Commit()或tx.Rollback()；Go 的defer容易漏掉错误分支的Rollback，建议用if err != nil { tx.Rollback(); return }明确兜底
示例片段：
func (h Handler) CreateOrder(c buffalo.Context) error {
tx, err := buffalo.DB.BeginTx(c.Request().Context(), nil)
if err != nil {
return err
}
defer tx.Close() // 注意：Close 不等于 Rollback，仅释放资源
user := User{Name: "Alice"}
_, err = tx.NamedExec("INSERT INTO users (name) VALUES (:name)", user)
if err != nil {
tx.Rollback()
return err
}
order := Order{UserID: user.ID, Amount: 99.9}
_, err = tx.NamedExec("INSERT INTO orders (user_id, amount) VALUES (:user_id, :amount)", order)
if err != nil {
tx.Rollback()
return err
}
return tx.Commit()
}
Beego ORM 与 Buffalo 共存时事务处理更复杂
如果你在 Buffalo 项目中同时引入了 Beego 的 ORM（比如为了复用其模型定义），要注意两者事务机制完全隔离：orm.NewOrm().Begin() 创建的是 Beego 自己的事务对象，和 buffalo.DB 无任何关联。跨框架混用会导致：
- 两个独立事务各自提交，无法保证原子性
- Beego ORM 的
Read()/Insert()默认走自己的连接池，不感知 Buffalo 的tx - 若强行把 Beego ORM 绑定到
buffalo.DB.DB底层*sql.DB，仍需手动传入*sql.Tx，且 Beego 不支持NamedExec等高级特性，容易出错
建议：要么统一用 buffalo.DB + 原生 SQL / sqlx，要么彻底切换为 Beego 框架——不要在 Buffalo 中“半途接入”Beego ORM 做事务协调。
嵌套事务和 Savepoint 在 Buffalo 中不可用
Buffalo 的 BeginTx() 不支持嵌套事务（即事务内再 BeginTx），也不提供 Savepoint 接口。如果业务需要局部回滚（比如批量导入中某条失败不影响其余），只能手动拆解逻辑：
- 把大事务拆成多个独立小事务，用状态字段标记中间进度
- 失败时靠应用层补偿（如插入失败记录表 + 后台重试）
- 避免依赖数据库级 Savepoint；PostgreSQL 虽支持，但
sqlx层未暴露该能力，Buffalo 更不会封装
真正需要 Savepoint 的场景，说明事务边界设计已超出 Buffalo 的适用范围，应考虑改用 dtm-labs/dtm 这类分布式事务框架，或重构为最终一致性流程。
