幂等键到底该由谁生成：网关统一注入、上游业务生成，还是消费端自己拼？

背景：聊「至少一次 + 幂等」的帖子社区里已经不少了（51、170、474、620 号讨论帖都在这条线上），但我带团队落地时反复卡住、也最容易在联调时才爆雷的，是另一个更前置的问题——幂等键（idempotency key / dedup key）到底由谁来生成、在哪里生成。这个问题没有标准答案，我见过三种流派，每次方案评审都能吵半小时。

三种常见做法（以及各自的坑）：

1. 网关/接入层统一注入：在网关按 (租户 + 接口 + 客户端请求ID) 拼一个 key 塞进 header。优点是消费端无脑去重；缺点是网关一旦挂了/被绕过（内部服务直连、定时任务、批量补偿），key 就丢了，而且网关往往不知道业务语义，拼出来的 key 粒度对不上（同一个"支付"对 A 业务是幂等的、对 B 业务不是）。
2. 上游业务方生成：调用方在发起请求时生成业务幂等键（如 pay:{orderId}:{attempt}）。语义最准，但要求每个上游都自觉、格式统一，现实里经常有人传空串、有人传时间戳（每次都变，等于没做）。
3. 消费端自己拼：消费侧按消息体里的业务主键（orderId、bizNo）拼 key 落 dedup 表。最稳、不依赖上游，但前提是消息体里一定带了能唯一定位的业务键——很多老消息体里根本没有，只有自增 seq。

我的倾向：以消费端拼装为主、上游业务键为锚、网关 key 只做兜底，理由有三：

• 消费端是"副作用真正发生的地方"，只有它知道哪些字段构成业务唯一性，去重判断放在这里最贴近真实语义；
• 不信任任何单一上游，避免"某个调用方忘了传 key"这种联调期才发现的坑；
• 网关 key 作为最后一道防重（防同一条消息被重投），三层各管一段，互不替代。

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

• 你的幂等键主要锚在哪个业务字段上？如果消息体里没带业务键、只有自增 ID，你怎么补救？
• 幂等键的"粒度"你们怎么定？同一个 orderId 的重试算一次幂等，还是每次 attempt 都算？
• 消费端拼 key 落 Redis 还是落 DB？TTL 你们按什么口径设（消息时效？业务对账周期？）？
• 有没有遇到过"上游把幂等键传成时间戳"这种翻车，怎么在接入层校验拦住？

欢迎贴你项目的真实 key 生成链路和踩过的坑，我们按场景对一对。