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

【背景】 去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径： 订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。

最初用 Kafka 事务（enable.idempotent = true），但发现事务管理复杂，且在多节点故障时容易出现一致性问题。

后来，我们尝试用 Outbox 模式 + 业务幂等，将幂等键存储到 MySQL，消费者端通过幂等键去重处理。

现在，我们正在考虑是否引入全链路事务（比如 Seata 或 Saga）来保证整个订单履约流程的原子性。

【常见分歧】

1. Outbox + 业务幂等：简单、易于实现，但需要业务层做幂等处理，容易漏掉某些场景。
2. 全链路事务：复杂，需要引入额外组件，但能保证整个链路的原子性。
3. Kafka 事务：成熟但复杂，容易受网络分区影响。

【你的倾向】 我倾向于 Outbox + 业务幂等，因为其简单且对现有系统侵入性小，但我也知道它存在一定的风险。

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

• 你们在什么场景下选择了 Outbox + 业务幂等？
• 有没有使用全链路事务的经验？
• Kafka 事务在你们的系统中是否可行？

欢迎分享你们的实践与思考！