项目中的幂等 ID 从哪里来，由谁生成？

核心回答

幂等 ID 标识一次业务动作，由能识别“同一次意图”的一方在首次尝试前创建，并在后续重试中复用。客户端可以生成请求令牌，业务服务也可以预先发放操作令牌；已有订单的支付、库存扣减或消费处理，则可以基于稳定业务标识再加动作类型生成键。

关键不是必须由前端还是后端生成，而是这个标识要跨网络重试保持稳定、在合法业务范围内唯一，并绑定调用方与请求内容。每次 HTTP 请求都生成一个新随机数，只能区分请求，无法识别它们其实在重试同一件事。

以创建订单为例

以下是可采用的设计示例：用户确认一次购买意图时生成 operationId，服务端在创建订单前持久记录 (userId, operationType, operationId)，通过唯一约束保证只有一次创建成功。成功后保存订单标识和可重用的响应。

后续请求携带同一操作标识：已完成时返回已有订单；处理中返回可查询状态；相同标识但商品、金额等关键参数发生变化时拒绝复用。请求摘要帮助发现键被误用，却不能单独代替操作标识，因为用户可能确实想连续购买两份完全相同的商品。

几种标识不要混用

订单号标识已创建的订单；在订单号尚未生成时，需要另一个稳定操作令牌识别创建动作。一次支付尝试、退款和创建订单也不是同一业务动作，不能不加区分地都只使用订单号。

分布式锁的随机持有者值用来确认谁能释放锁，不承担业务去重。消息系统的投递标识也未必等于业务事件标识；业务事件重发时应保留原事件标识。

幂等记录保留期覆盖合理的重试、消息重投和对账窗口。对账务等长期约束，保留永久业务唯一性，不能只依赖一个很快过期的缓存标记。

对应教程

参考资料