微服务遇到重试时，先把幂等键设计好

网络抖动、超时或客户端重复点击，都可能让同一个业务请求到达服务多次。微服务之间如果只依赖“调用成功”来判断结果，重试很容易变成重复扣款、重复创建或重复发通知。设计应用时，可以先把幂等规则写清楚，再决定重试策略。

一、先确定请求的唯一标识

幂等键应由业务方生成，并随着同一次操作一直传递。它不能只使用当前时间或随机拼接的字符串，而应与业务对象和操作意图有关。例如创建订单、提交审批、发起退款，都可以让调用方为一次操作生成唯一编号。服务端要明确哪些字段参与生成，避免同一业务被误判为不同请求。

二、记录处理状态和结果

收到请求后，服务端可以先检查幂等键是否已经存在。首次处理时写入处理中状态，完成后保存成功结果或可重试的失败状态。后续相同请求应返回已有结果，而不是再次执行副作用操作。状态记录要和业务更新放在一致的处理边界内，不能出现业务已完成但幂等记录没有落下的情况。

三、划清重试范围

连接超时并不代表服务端没有执行成功，因此客户端重试前要区分网络异常、参数错误和业务拒绝。对于可以安全重试的场景，设置次数上限和退避间隔；对于不可重试的错误，直接返回明确原因。服务端也应避免在每一层都自动重试，否则一次调用可能被放大成多次。

四、让异常可追踪

日志中同时记录幂等键、业务编号、调用方和最终状态，排查时才能把重复请求串起来。监控可以关注同一幂等键的重复到达、处理中超时和失败重试次数。对于长期未完成的记录，安排人工或补偿流程，并保留处理依据。

幂等键不是简单加一个字段，而是把请求身份、状态变化和重试边界连成一套规则。先定义清楚，再接入微服务调用链，系统在面对重复请求时才更容易保持一致。