在单体架构时代，事务靠数据库的 ACID 就能兜底；一旦服务拆成微服务，一笔业务跨越订单、库存、账户三个独立数据源时，@Transactional 就彻底失效了——每个服务的事务都是"局部自治"的，任何一个环节失败都不会回滚别人已经提交的改动，最终落得一地数据不一致。本文不打算泛泛介绍"什么是分布式事务"，而是从工程视角拆解四种主流方案的取舍，再深入 Seata AT 模式的两阶段提交、全局锁与 undolog 细节，最后给出我在生产环境踩过的坑与调优清单。

一、先想清楚：为什么大部分场景首选"最终一致性"