业务幂等 token 到底该按请求、按交易还是按业务流来定？聊聊你的取舍

背景 最近带团队重排一套支付/订单链路的重试策略，发现一个老问题被反复提起却没人真正对齐：业务幂等键（idempotency key）到底应该按什么粒度生成。网关层、业务层、存储层各自都能做去重，但"谁负责、按什么 key 去重"在团队里至少有三种做法，争论了两个月。

常见分歧（我见过的几种主流做法）

1. 按"请求"做幂等：客户端每次调用生成一个 UUID 放在 header，网关/业务层用 Redis SETNX 去重，TTL 一般 5–30 分钟。优点是简单、跨服务通用；缺点是重试窗口一过 key 就丢，且客户端重发时往往换一个新 UUID（业务侧其实是"同一笔"），等于没幂等。
2. 按"业务交易"做幂等：用业务唯一键（订单号、支付流水号、合同号）作为 key，落库时唯一索引兜底。优点是天然幂等、可追溯；缺点是不同动作（下单/支付/退款）语义不同，需要 (bizKey, action) 复合键，且跨服务时"同一笔交易"的边界很难划清。
3. 按"业务流/流程实例"做幂等：把一次用户操作（如下单→支付→发货）建模成一个 workflow，每步用 (workflowId, stepId) 做幂等。优点是对"重试整条链路"最稳；缺点是引入流程引擎后，幂等和流程状态强耦合，排查成本上升。

我的倾向 我个人偏 方案 2 + 在关键动作上叠加方案 1：

• 业务幂等键一定落到数据库唯一索引，不能只靠 Redis——Redis 挂了 / TTL 过期不能成为"重复扣款"的理由；
• 网关层再做一次 (clientId + requestId) 的短 TTL 去重，只用来挡"网络抖动重放"，不作为业务正确性的最终防线；
• 跨服务的"同一笔交易"边界，用业务方约定的 bizKey 显式传递，而不是靠 traceId 猜。

理由：10 年里我复盘过的 7 次重复扣款事故，6 次的根因是"以为 Redis 去重就够了"，第 1 次是 traceId 被中间件换了导致客户端以为换了新请求。把幂等键下沉到唯一索引 + 业务语义化，是把"幂等"从"尽力而为"变成"强约束"的关键一步。

想听大家聊的

1. 你们生产环境里，幂等键到底按什么粒度生成？是 (clientId, requestId) 还是 (bizKey, action) 还是 (workflowId, stepId)？
2. 跨服务（A→B→C）时，下游 B 怎么知道"同一笔交易"的边界？是上游显式传 bizKey，还是 B 自己按业务语义推导？
3. 你被幂等坑过最惨的一次是什么场景？是 Redis 丢 key、traceId 被换、还是"退款"和"撤销"被当成同一个动作？
4. 有没有人在生产里真的用 workflow 引擎（Camunda/Temporal/自研）来做幂等？效果如何，运维成本划不划算？

欢迎带具体数字和踩坑细节来聊，纯观点输出我会礼貌跳过。