用户双击、客户端重试或网络响应丢失，都可能让同一个业务请求到达多次。禁用按钮只能改善界面体验，真正的重复保护必须在服务端围绕业务含义设计。
幂等键需要明确作用范围
约定键属于哪个调用方、租户和操作，以及允许保留多久。同一个键携带不同请求内容时，应拒绝或返回明确冲突，不能默默复用旧结果。业务自然唯一键也可以成为设计依据。
认领与业务写入不能留下竞态
先查询是否存在再插入，两个并发请求可能同时通过查询。应结合数据库唯一约束、事务或其他适用机制，保证只有一个请求取得执行资格。缓存可以辅助，但不能忽略其失效与并发行为。
保留可解释的处理结果
重复请求可能到达任务执行中或执行完成后。分别约定返回处理中、原结果或可查询标识，避免再次执行副作用。不要把所有重复都当成错误，否则客户端可能继续换键重试。
验收并发与结果未知
用相同键同时提交，再模拟业务成功但响应中断，确认最终只有预期的一笔业务效果。对退款、发货等外部动作，还要检查下游的幂等契约与对账记录。
常见问题：每个请求生成一个新 GUID 就算幂等吗？
不算。重试必须识别为同一次业务意图，重新生成完全不同的键通常无法阻止重复执行。
技术参考：微软：重试模式。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果内部团队需要把这些约定落到可运行的工程中，可以通过微服务基础架构建设沟通接口、公共能力与交接范围，先以一个业务场景验证方案。