消息队列到底要不要追求「精确一次」？还是至少一次 + 幂等就够了

背景：团队里只要一动到消息中间件，绕不开的一个老问题是投递语义。面试和方案评审里几乎必问一句：「你们是 at-least-once 还是 exactly-once？」我的经验是，这个问题背后藏着一个被过度神话的概念——很多团队嘴上说要做精确一次，其实真正落地的还是「至少一次 + 消费端幂等」，只是没人愿意把这句话摊到台面上写进设计文档。

常见的几种做法，我观察到分歧很明显：

1. 一派追求「端到端精确一次」，用事务消息 / 事务性 producer + 消费端事务 + 幂等键，链路每一环都上锁上事务，追求「一条消息恰好生效一次」。代价是复杂度陡增，跨服务一致性要靠 2PC 或事务协调器兜底，性能也吃亏。
2. 一派直接放弃语义保证，只做「至少一次」，把「去重」的责任全甩给消费端：本地唯一键、去重表、幂等 ID。链路简单、吞吐高，但要求每个下游都自觉做幂等，一旦某个消费方偷懒就埋雷。
3. 一派折中：生产端 at-least-once，关键路径（扣款、记账）做幂等，非关键路径（埋点、日志、缓存预热）允许重复。

我的倾向：绝大多数业务场景，「至少一次 + 消费端幂等」是更稳的工程解，而不是「精确一次」。理由有三：第一，真正精确一次的实现依赖 broker 与所有下游的一致性事务，任何一环降级都会把「恰好一次」退化成「多次或零次」，你其实并没有真的精确，只是更贵更复杂；第二，幂等是消费方本来就该具备的能力，把去重责任内聚到读侧，链路才解耦；第三，重复消费在多数业务里是「可接受的成本」，而为了消灭它付出的协调开销往往是「不可接受的成本」。但我要强调：这要求你清楚区分哪些下游「必须幂等」、哪些「可以容忍重复」，这个分类比技术选型本身更重要。

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

• 你们在「扣款 / 记账 / 状态机流转」这种强一致路径上，是真上了事务消息，还是也靠幂等表兜底？幂等表你们怎么设计（唯一键 + 状态机 + 有效期）？
• 消费端幂等，你们是「先查后写」还是有更稳的做法？并发重复消息（同一条被两个 consumer 同时拉到）你们怎么处理？
• 有没有哪个场景你试过「精确一次」最后发现不如「至少一次 + 幂等 + 补偿」稳的？

欢迎贴你们的具体做法和踩坑，我特别想收集「幂等表在高频下的性能问题」这类工程细节。