幂等性
分布式系统和API设计中的核心概念，指同一操作执行一次与执行多次产生的结果完全相同，是API重试机制设计的重要考量
核心事实
时间轴 (近 90 天)
幂等性设计要求系统能识别重复写入请求并安全拒绝或合并，而不是盲目执行两次
对非幂等的写操作进行安全重放前，必须通过特征标记（如Idempotency-Key请求头）或环境隔离来防止重复副作用
幂等性是指一个操作被执行一次与被执行多次产生的效果相同，GET请求通常是幂等的而POST/PATCH等写操作不一定
实现幂等性的常见手段包括为每次操作分配唯一请求ID（Idempotency Key），服务端以此去重
数据库的 INSERT ... ON CONFLICT DO NOTHING 通过内部状态检查天然支持幂等
发送邮件本身不是幂等操作，只有当邮件服务商接受请求并返回 message id 后才能确认邮件已发出
在 HTTP 语义中，GET、PUT、DELETE 被定义为幂等方法，而 POST 通常不是
需要先明确业务能容忍最多一次还是最少一次语义，若漏发比重发更不可接受则应倾向激进重试并配合下游去重
在幂等记录中增加状态字段标记请求所处阶段，可使接管进程根据状态判断是否安全重试，而非一刀切地重发或阻塞
让下游服务商具备去重能力可以将幂等责任下沉一层，即便发生双重发送下游也能识别并去重
还有 13 条时间轴事件
全部知识事实 (20)
幂等性（idempotency）是分布式系统设计中的关键原则，指同一操作执行一次和多次的效果完全相同
70%已验证在HTTP协议规范中，GET、PUT、DELETE被定义为幂等方法，而POST不是
70%已验证幂等性是指同一操作执行一次与执行多次产生的效果完全相同的性质，HTTP PUT/DELETE方法和数据库INSERT OR IGNORE语义都是典型案例
70%待验证防止重复扣费的幂等性实现方案包括数据库唯一约束、状态机检查、Redis分布式锁和乐观锁版本号
90%待验证幂等性指同一操作无论执行一次还是多次最终结果应相同，常见实现是为每次请求生成全局唯一请求ID（如UUID）供服务端去重
60%待验证GET、PUT、DELETE均为幂等操作，而POST是非幂等的
60%待验证幂等性设计要求系统能识别重复写入请求并安全拒绝或合并，而不是盲目执行两次
50%待验证对非幂等的写操作进行安全重放前，必须通过特征标记（如Idempotency-Key请求头）或环境隔离来防止重复副作用
50%待验证幂等性是指一个操作被执行一次与被执行多次产生的效果相同，GET请求通常是幂等的而POST/PATCH等写操作不一定
50%待验证实现幂等性的常见手段包括为每次操作分配唯一请求ID（Idempotency Key），服务端以此去重
50%待验证在幂等记录中增加状态字段标记请求所处阶段，可使接管进程根据状态判断是否安全重试，而非一刀切地重发或阻塞
50%待验证需要先明确业务能容忍最多一次还是最少一次语义，若漏发比重发更不可接受则应倾向激进重试并配合下游去重
50%待验证在 HTTP 语义中，GET、PUT、DELETE 被定义为幂等方法，而 POST 通常不是
50%待验证数据库的 INSERT ... ON CONFLICT DO NOTHING 通过内部状态检查天然支持幂等
50%待验证让下游服务商具备去重能力可以将幂等责任下沉一层，即便发生双重发送下游也能识别并去重
50%待验证发送邮件本身不是幂等操作，只有当邮件服务商接受请求并返回 message id 后才能确认邮件已发出
50%待验证实现幂等性的常见手段包括为每次写操作分配唯一的请求ID（idempotency key），或采用条件写入（compare-and-swap）仅当目标数据处于预期状态时才执行写入
50%待验证在Agent场景下，幂等性保障不能只依赖调用方自律，必须在工具层（Tool Layer）或操作系统接口层强制实施
50%待验证设计良好的检查点系统需要解决幂等性问题，即从检查点恢复后重新执行某些步骤不会产生副作用
50%待验证只有对系统状态没有副作用、或重复执行结果一致的操作（如 GET 请求、带幂等键的写操作）才应当被自动重试；对普通 POST 创建请求盲目重试可能导致资源重复创建
50%