beego orm 不支持跨数据库 alias 的分布式事务回滚，因其事务基于单 *sql.tx，无两阶段提交机制；多 alias 的 begin() 互不感知，强行调用会导致数据不一致；应采用应用层补偿+幂等设计实现最终一致性。
Beego 框架本身不支持分布式事务回滚，任何跨数据库 alias 的事务操作都无法保证原子性提交或回滚。 它的 orm.Begin() 只能绑定单个数据库连接（即单个 *sql.Tx），底层没有两阶段提交（2PC）或协调器机制。强行在多个 alias 上调用 Begin() 并分别 Commit()/Rollback()，只会得到各自独立的结果——一个成功、一个失败，数据必然不一致。
为什么 Beego 的 orm.Transaction 不能跨 alias 回滚
Beego ORM 的事务模型完全基于 Go 标准库 database/sql 的单连接事务语义。每个 orm.RegisterModel 绑定的 alias（如 "default"、"slave"、"pg"）对应独立的 *sql.DB 实例，而 *sql.Tx 无法跨 *sql.DB 共享或协调。
- 调用
orm.Begin("default")和orm.Begin("pg")会生成两个互不感知的事务上下文 - 即使你在代码里用
defer tx.Rollback()包裹，也只对当前 alias 生效 - MySQL 的
XA START/END/COMMIT/ROLLBACK命令需手动驱动且 Beego ORM 不封装，也不自动参与 - Beego 日志中不会报错，但业务逻辑上已出现“伪事务”假象——表面流程走完，实际数据分裂
替代方案：应用层补偿 + 幂等设计
当必须操作 MySQL 和 PostgreSQL（或其他异构库）时，放弃“统一回滚”幻想，改用最终一致性策略。核心是把事务拆成可重试、可校验、可反向的操作单元。
- 先在主库（如 MySQL）写入状态为
"pending"的订单记录，并记下关联的 PostgreSQL 侧业务 ID - 再调用 PostgreSQL 的插入逻辑；若失败，立即用 MySQL 中的记录触发补偿任务（例如发 MQ 或跑定时 Job）
- 所有写操作必须带唯一业务幂等键（如
order_no），PostgreSQL 插入前先SELECT ... FOR UPDATE或用INSERT ... ON CONFLICT DO NOTHING - 避免在同一个 HTTP 请求中强依赖两次 DB 写入结果；把第二步下沉为异步事件，用 Beego 的
bee run -d启动后台协程或对接 goframe 的gtask模块
Beego 中模拟“类事务”的安全写法示例
以下是在单 alias 内确保事务完整性的最小可靠模式：
o := orm.NewOrm()
o.Using("default") // 显式指定 alias，避免隐式 fallback
tx, err := o.Begin()
if err != nil {
return err
}
defer func() {
if r := recover(); r != nil {
tx.Rollback()
panic(r)
}
}()
// 所有 DB 操作必须通过 tx 对象
qs := tx.QueryTable(&Order{})
_, err = qs.Filter("id", 123).Update(orm.Params{"status": 2})
if err != nil {
tx.Rollback()
return err
}
err = tx.Commit()
if err != nil {
tx.Rollback()
return err
}
注意：tx.QueryTable() 和 tx.Read() 等方法才真正走事务通道；直接用 orm.NewOrm().QueryTable() 会绕过事务，导致部分写入生效。
最容易被忽略的是：Beego 的 orm.Debug = true 日志里只显示 SQL，不体现事务归属；你得靠日志中是否出现 BEGIN/COMMIT/ROLLBACK 关键字，以及执行顺序，来人工确认事务边界是否被意外打断。一旦混用普通 orm 实例和 tx 实例，就等于在事务里开了后门。
