由 dawei Go语言本身不直接提供分布式事务支持，MySQL的本地事务（如BEGIN/COMMIT）仅限单库生效，跨库或微服务场景需借助外部协调机制。
最常用的是二阶段提交（2PC），由协调者统一调度多个MySQL实例的Prepare、Commit或Rollback。Go中可使用database/sql配合自定义事务管理器，但需自行实现Prepare阶段的持久化日志（如写入XA事务表），确保崩溃后可恢复。
MySQL原生支持XA事务，通过xa_start、xa_end、xa_prepare、xa_commit等语句操作。Go可通过sql.Exec调用，但须注意：XA事务不兼容连接池自动复用，每次XA操作需绑定同一底层连接，通常需禁用连接池或手动AcquireConn保证连接独占。
AI生成内容图，仅供参考
实际生产中，强一致性2PC存在性能瓶颈与单点风险，越来越多团队转向柔性事务方案。Saga模式在Go生态中较易落地——将全局事务拆为一系列本地事务，每个步骤配对补偿操作（如正向扣款+反向退款），用消息队列（如Kafka、NATS）驱动状态流转，结合go-saga等轻量库实现状态机编排。
TCC（Try-Confirm-Cancel）适用于业务逻辑明确隔离的场景。Go中需开发者显式定义Try（资源预留）、Confirm（正式提交）、Cancel（释放预留）三个接口，利用Redis或MySQL记录事务状态，配合定时任务扫表处理悬挂事务。
无论选择哪种方案，日志是关键基础设施。所有关键决策点（如Prepare成功、消息发送、补偿触发）都必须落盘，推荐使用结构化日志（如zerolog）并关联全局traceID，便于问题追踪与审计。
值得警惕的是：盲目追求强一致可能损害可用性。多数业务场景可通过幂等设计、最终一致性加对账补偿达成更优平衡。例如订单支付中，先写订单再异步通知库存，辅以T+1对账与人工干预通道，反而比跨服务2PC更健壮可靠。