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

【背景】 我们团队在订单履约链路中使用Kafka 3.5（KRaft，3 broker），核心路径是：订单创建 → 写MySQL → 发Kafka消息 → 消费者调外部物流API。最初用Kafka事务（enable.idempotent=true）+ 生产者acks=all，但发现存在消息丢失风险。

【常见分歧】

1. Outbox模式：

• 优点：数据库事务保障，业务幂等处理
• 缺点：需要维护额外表，复杂度上升

2. 全链路事务：

• 优点：端到端一致性
• 缺点：性能开销大，分布式事务复杂

【我的倾向】 我们最终采用Outbox+业务幂等的混合方案：

1. 用MySQL事务保证消息写入原子性
2. 消费端用唯一业务ID做幂等校验
3. 保留Kafka事务作为降级方案

【想听大家】

1. 你们在什么场景下选择哪种方案？
2. 有没有遇到过「看似正确但实际失败」的选型案例？
3. 对Kafka 3.5+的新特性（如Transactional Messages）有何实际反馈？