beego ORM 事务仅作用于单个数据库连接，不支持跨库、跨服务或分布式事务。需手动管理 commit/rollback，原生 SQL 需用 ? 占位符，多库操作须应用层补偿。
beego ORM 的事务只作用于单个数据库连接
beego 的 orm.Begin() 生成的 TxOrm 实例，完全绑定在当前注册的数据库 alias（比如 "default"）上。它不感知、也不协调其他数据库或外部服务——哪怕你配置了 "dev" 和 "test" 两个库，tx := orm.NewOrm().Begin() 也只会开启默认库的事务。
常见错误现象：user.Insert() 成功，紧接着调用 http.Post("order-service/create") 失败，但用户数据已提交无法撤回。
- 根本原因：HTTP 调用与数据库事务无上下文关联，beego 不提供跨进程事务传播能力
- 兼容性影响：无论后端是 MySQL、TiDB 还是 PostgreSQL，只要不是同一 DB 实例，
orm.Transaction就无法覆盖分布式操作 - 别指望
@Transactional或类似注解——beego 没有该机制，orm.RunSync()也不是事务同步器，只是模型同步工具
手动管理事务时必须显式 commit 或 rollback
如果你用 tx, err := orm.NewOrm().Begin() 开启事务，但既不调用 tx.Commit() 也不调用 tx.Rollback()，这个连接会一直挂起，直到超时或被连接池回收。更危险的是：某些驱动（如 MySQL）可能在连接关闭时自动回滚，但行为不可靠，且日志中几乎不报错。
- 典型坑：代码里写了
goto ERR，但忘记在ERR标签里调用tx.Rollback() - 正确做法：用
defer+recover()或明确的 if 分支兜底，确保任何路径都触发结束动作 - 示例片段：
tx, err := orm.NewOrm().Begin() if err != nil { return err } defer func() { if r := recover(); r != nil { tx.Rollback() panic(r) } }() // ... 执行操作 if someErr != nil { tx.Rollback() return someErr } return tx.Commit()
多数据库事务需分别控制，无法原子联动
beego 不支持跨 alias 的事务合并。你想在 "user_db" 插入用户、同时在 "log_db" 写操作日志并保证两者一起成功？不行。你只能分别开启两个事务，各自处理，再靠应用层逻辑兜底补偿。
- 配置上必须用前缀区分：
dev_dbhost、log_dbhost，不能重复用dbhost - 使用时必须显式指定：
o1 := orm.NewOrmWithDB("user_db")、o2 := orm.NewOrmWithDB("log_db") - 每个
Begin()都独立：一个失败不影响另一个，但你也无法回滚另一个 - 若强一致性要求高，应合并为单库设计，或改用消息表+异步投递实现最终一致性
事务内执行原生 SQL 需注意参数绑定和驱动兼容性
在事务中用 tx.Raw("UPDATE ...").Exec() 是可行的，但要注意：参数占位符必须用 ?（MySQL 驱动），而非 $1（PostgreSQL）。否则会报 sql: expected 0 arguments, got 1 或直接 panic。
- 安全写法：统一用
?，由 beego ORM 自动适配驱动（MySQL/SQLite 支持良好，PostgreSQL 需确认驱动版本） - 避免字符串拼接 SQL，尤其涉及用户输入——
tx.Raw("UPDATE t SET name = '" + name + "'")会绕过参数绑定，引发注入 - 执行失败时，
Exec()返回的error不等于事务终止；必须自己判断并调用tx.Rollback()
事务本身不难写，难的是边界意识：它只管当前 DB 连接里的那几行数据，不管 HTTP、RPC、文件、缓存、MQ。一旦跨出这个边界，就得靠业务逻辑补位，而不是寄希望于框架自动兜底。
