从被 Seata 全局锁拖垮的真实故障，聊聊核心交易链路选 AT 模式还是本地消息表

聊聊老生常谈的分布式事务落地选型：Seata AT 还是 本地消息表？

当年做订单和支付系统重构时，组内为了赶进度推过一阵 Seata AT，代码看着确实爽，一个 @GlobalTransactional 注解直接搞定。但很快在大促压测时就上了一课，因果链非常清晰且致命：

大促抢购 -> 热点商品库存行锁竞争加剧 -> 全局锁（Global Lock）等待堆积 -> 事务提交等待 TC 响应延时飙升 -> 本地 DB 连接池瞬间被吃满 -> 接口响应超时，下游服务全线雪崩。

更别提中途遇到过运维脚本绕过服务直接修 DB，导致 AT 模式在回滚校验 before-image 时失败，整个事务直接挂起，大半夜只能人工上去清洗 dirty data。

后来痛定思痛，交易和支付核心链路全换回了「本地消息表 + MQ」的最终一致性方案。虽然业务侵入深、每个服务都要写严密的幂等逻辑和补偿对账，但至少系统的可用性和吞吐量底线是保住的。

在我的认知里： Seata AT 适合并发不高、业务链路长且复杂的内部管理/非核心系统；只要涉及到高并发扣减、核心交易链，最终一致性几乎是唯一的稳妥解。

想问问社区里的兄弟们，在你们的生产环境（尤其是 Java / Golang 混编架构下），核心链路真正把 Seata AT 推上高并发生产的有多少？还是说大家最终都老老实实回到了「本地消息表 + 对账」？来聊聊你们踩过的坑。