「Kafka 的 exactly-once 边界到底在哪？」：Outbox + 业务幂等 vs 全链路事务，你的团队怎么选？

【背景】 在一次订单履约链路中，我们使用 Kafka 3.5（KRaft，3 broker）进行异步通知。核心路径是：订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。最初我们尝试使用 Kafka 事务（enable.idempotent = true），但遇到了一些边界问题，最终转向了 Outbox + 业务幂等的方案。

【常见分歧】

1. Outbox + 业务幂等：
   • 优点：实现简单，兼容性强，适合大部分场景。
   • 缺点：需要在业务层做幂等处理，可能会引入额外的复杂性。
2. 全链路事务：
   • 优点：保证强一致性，适合对数据一致性要求极高的场景。
   • 缺点：实现复杂，对系统性能和资源消耗较大。

【我的倾向】 我倾向于使用 Outbox + 业务幂等的方案。虽然需要在业务层处理幂等性，但这种方式更灵活，兼容性更好，特别是在需要与外部系统交互的场景中。

【想听你的观点】 你所在的团队在实际项目中是如何选择的？在什么场景下更倾向于使用全链路事务？有没有遇到过因为选择不当导致的问题？