消息「至少一次 + 幂等」还是「恰好一次」？我为什么倾向前者

背景：做异步链路时几乎绕不开一个选择题——消费端到底按「至少一次投递 + 业务幂等」来设计，还是去追框架宣传的「恰好一次（exactly-once）」？我带团队处理订单、支付、库存这类有副作用的链路时，反复在这个点上和新人、和别的团队掰扯，发现大家的「直觉答案」几乎相反：有人一听 exactly-once 就觉得一劳永逸，有人则坚信幂等才是唯一靠谱的路。我想把这个分歧摊开聊聊。

几种常见做法与各自代价：

1. 纯「至少一次 + 重试」，不做幂等。最省事，但下游一旦重复消费，库存多扣、重复发货、重复打款，事故等级直接拉满。多数团队的第一版都长这样，然后被一次线上事故教育。
2. 全链路幂等：用业务唯一键（订单号、流水号）+ 数据库唯一约束或状态机做去重。可复现的做法是：消费前查「已处理流水表」，命中则直接 ack 跳过；落库时靠唯一索引兜底，INSERT 冲突当作「已处理」返回成功。幂等键要覆盖「重试窗口 + 时钟回拨」，TTL 别设太短。
3. 依赖 MQ 的事务消息 / 两阶段（RocketMQ 事务消息、Kafka transactional producer）去逼近 exactly-once。工程上确实能减少重复，但「恰好一次」几乎只在「单一系统内、且下游无外部副作用」时才成立；跨服务、跨存储、带第三方调用时，事务边界根本圈不住，剩下的重复仍要业务幂等兜底。

我的倾向与理由：我默认按「至少一次 + 幂等」设计，把 exactly-once 只当作「减少重复、降低幂等压力」的优化项，而不是正确性来源。理由有三：其一，副作用（改库存、调支付、发短信）天然不可事务化，重复是物理上消不掉的，只能靠幂等吸收；其二，幂等的判定逻辑是「业务语义」，放在业务层最可控，框架的 exactly-once 语义一旦和你的状态机对不齐，反而更难排查；其三，幂等表 + 唯一索引这套东西在大多数场景下成本可控，收益却是「重复来了也不出事」，这是兜底能力，不该赌在框架语义上。

想听大家：

• 你们在「有外部副作用」和「纯内部落库」两类场景下，分别怎么选？
• 幂等键的 TTL / 去重窗口你们一般怎么定，有没有踩过「窗口太短导致重试被当新请求」的坑？
• 有人真的把 MQ 的 exactly-once 当正确性来源在用吗？边界划在哪？