幂等设计是防重复也是防补偿失败

幂等常被理解成防止用户重复点击。这个理解没错，但还不够。真实系统里，消息重试、定时补偿、网络超时后的再次请求，也都需要幂等保护。

先找到业务唯一性

幂等的关键是找到业务上能代表同一次动作的唯一标识。它可以来自请求号、订单号、流水号，也可以来自业务字段组合。没有稳定标识，幂等就只能靠猜。

这个标识应该由调用方和服务方共同约定。调用方负责传入，服务方负责校验和落库。

有些场景只靠请求号去重还不够。比如支付回调、发货确认、审批流转，更可靠的方式是结合当前业务状态判断是否允许继续执行。

如果订单已经完成，再收到完成通知，就应该识别为重复事件，而不是再次执行后续动作。状态机是幂等设计的重要基础。

补偿任务经常会重跑。如果补偿逻辑不幂等，原本是修复数据，结果可能制造更多重复数据。比如重复发消息、重复写流水、重复调用外部接口。

我会把补偿任务当作普通业务入口一样设计幂等，而不是把它当成一次性的脚本。

幂等设计不是为了应付重复点击，而是为了让系统面对重试、超时、补偿和乱序时仍然可控。越是关键业务，越应该把幂等当成基础设计。