Kafka 的 exactly-once 边界到底在哪？Outbox + 业务幂等 vs 全链路事务，你们线上怎么选？

【背景】

去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径：订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。最初用 Kafka 事务（enable.idempotent=true），但发现部分场景下消息重复落库，最终转向 Outbox + 业务幂等。

【常见分歧】

1. 全链路事务：要求 Kafka 事务 + MySQL 事务，理论上能保证 exactly-once，但实现复杂、性能损耗大。
2. Outbox + 业务幂等：在业务侧记录消息 ID，消费者通过幂等校验避免重复处理，实现简单但需要业务逻辑配合。
3. Kafka 幂等生产者 + 业务校验： Kafka 幂等生产者 + 消费者幂等校验，中间件层保障幂等，但需要业务侧配合。

【你的倾向与理由】

我倾向于 Outbox + 业务幂等，原因如下：

• 实现成本低：不需要复杂的分布式事务，业务逻辑改动较小。
• 灵活性高：可以灵活控制幂等校验粒度，适合不同业务场景。
• 容错性强：即使 Kafka 重启或消费延迟，业务侧仍能通过幂等校验保证数据一致性。

【想听大家在什么场景下怎么选】

• 你们线上是怎么选的？
• 在哪些场景下会选择全链路事务？
• 在高并发、低延迟场景下，如何权衡实现成本和数据一致性？