beego 不支持分布式事务，需用“本地事务+异步补偿”实现最终一致性：第一步同事务写业务表和消息表；第二步用 time.ticker 扫描并发送 mq；第三步消费端幂等处理。
Beego 本身不提供分布式事务能力，也没有内置的 TCC、SAGA 或 XA 支持。想在 Beego 项目中实现最终一致性，必须绕过框架限制，用“本地事务 + 异步补偿”这一底层可落地的模式，而不是寄希望于 beego.Controller 或 orm.Transaction 能跨服务生效。
为什么不能直接用 Beego 的事务封装做分布式事务
Beego 的 orm.Begin() / orm.Commit() 只作用于单个数据库连接（哪怕你配了多个数据源，它也不会自动协调）。调用 http.Post 或 rpc.Call 去另一个服务，和本地事务完全无关——数据库提交成功后网络失败，或对方服务处理出错，Beego 不会回滚已提交的本地数据。
- 错误现象：
user.Insert()成功，http.Post("inventory-service/deduct")超时，用户看到“下单成功”，但库存没扣 - 根本原因：Beego 没有跨进程/跨网络的事务上下文传播机制
- 兼容性影响：无论你用 MySQL、PostgreSQL 还是 TiDB，只要不是同一 DB 实例，
orm.Transaction就无法覆盖分布式场景
Beego 中落地本地消息表的三步关键动作
核心是把“业务操作”和“发消息”塞进同一个本地事务，靠定时任务驱动投递，用幂等消费兜底。Beego 作为 Web 层，只负责前半段写库，后半段交给独立协程或外部调度器。
- 第一步：在业务逻辑里，用
orm.RunSync()或显式tx := orm.NewOrm().Begin()同时写业务表和消息表
例如注册送积分：先user.Insert()，再message.Insert(&Message{Topic: "points", Payload: `{"uid":123,"amt":10}`})，共用一个tx - 第二步：避免用
@Scheduled（Beego 无此注解），改用time.Ticker启动后台 goroutine 扫描message表中status = 'pending'的记录，调用mq.Publish()发送到 RocketMQ/Kafka，并在成功后更新status = 'sent' - 第三步：消费端（可以是另一个 Beego 服务）监听 MQ，收到消息后先查本地
points_log表确认是否已处理（幂等 key：比如uid+event_id），未处理才执行points.Add()并落日志
容易被忽略的四个坑
很多团队卡在这几步上导致最终一致性失效，不是方案不行，而是细节没控住。
-
message表必须和业务表在同一个数据库实例、同一个 schema 下，否则本地事务无法保证原子性 - 定时扫描任务不能只靠
SELECT ... FOR UPDATE，要加WHERE status = 'pending' AND next_retry_at ，否则失败消息会无限重试压垮 MQ - MQ 投递成功但网络抖动导致 Beego 没收到 ACK，此时应先更新
status = 'sending'再发消息，避免重复发送 - Beego 默认日志不打 SQL 参数，调试消息表写入失败时，得手动在
orm.Debug = true下看完整 SQL 和错误码，常见的是ERROR 1205 (HY000): Deadlock found
最终一致性的“最终”二字，本质是把强一致的实时压力，转化成可预测的异步修复窗口。Beego 不帮你做这个转化，但也不拦着你做——关键在消息表结构设计、重试策略粒度、以及消费端幂等逻辑是否真正覆盖所有异常路径。这些地方一旦松动，就不是“短暂不一致”，而是“永久丢失”。
