幂等到底该在业务层写，还是下沉到 SDK/网关统一做？

先交代背景。做中间件这些年，我几乎每个项目都会被问一句："幂等你们怎么做的？"答案五花八门——有人业务层每张表加唯一索引，有人用 Redis SETNX + TTL，有人在网关层按 (userId, path, bodyHash) 去重，还有人干脆把请求号（requestId / bizNo）透传到所有下游，让每一跳自己判断。热榜上那篇「超时与重试」讲得很透，但只解决了"重试会发生"的问题，没解决"重试之后谁负责不重复"的问题——这恰恰是幂等要回答的。

常见的分歧我大致归成三派：

第一派：幂等是业务语义，必须业务层做。理由很简单——"重复扣款"和"重复查询"是完全不同的事，只有业务才知道哪些操作要幂等、幂等的键是什么（订单号？流水号？用户+商品+时间窗口？）。中间件如果统一做，要么键设计得太粗导致误判，要么太细等于没做。

第二派：幂等是基础设施能力，应该下沉到 SDK 或网关。理由：让每个业务同学自己写一遍 Redis 锁 + 唯一索引 + 异常回滚，代码质量参差，出了事就是 N 套实现 N 种 bug。统一做，一套代码、一套监控、一套降级策略，可维护性高得多。

第三派：分层协作。网关层做"粗粒度去重"（同一 requestId 短时间重复直接拒绝），SDK 层提供"幂等装饰器"（业务声明 key 和 TTL，SDK 负责 Redis 交互和异常处理），业务层只定义"什么算一次操作"。

我个人的倾向是第三派，但有一个前提：幂等键的语义必须留在业务层。打个比方，网关像小区门卫，能认出"你这 30 秒内来过三次，别再刷了"，但它不可能知道"你上次取的那个快递是不是同一单"。SDK 像快递柜，提供"凭码取件"的机制，但码是什么、有效期多长，得寄件人定。如果让门卫或快递柜去猜"这算不算同一单"，一定会出幺蛾子。

想听听大家在几种具体场景下的选择：

1. 支付/资金类接口：幂等键是上游生成还是本服务生成？TTL 怎么定？
2. 异步消息消费（Kafka/RocketMQ）：幂等是消费端做还是 broker 侧做？重投窗口多长？
3. 跨服务编排（A→B→C）：幂等键要不要全链路透传？B 和 C 的幂等键是同一个还是各自独立？
4. 你们团队里，幂等代码是"公共组件"还是"每个服务自己写"？维护成本差异大吗？

欢迎带具体案例来聊，越具体越好。