idempotency_key 必须通过数据库唯一约束（如 PostgreSQL INSERT ... ON CONFLICT）实现强一致性校验，而非仅靠内存缓存或应用层判断；需绑定时效性（X-Timestamp）与完整性（HMAC-SHA256 签名），并针对第三方支付提取业务唯一标识做状态机幂等。
回调地址收到重复请求时，idempotency_key 怎么用才有效
很多开发者把 idempotency_key 当成“加个 header 就完事”，结果发现重放请求照样扣款、发短信、创建订单。根本原因：没在业务逻辑里真正校验和落库锁住这个 key。
正确做法是收到请求后，立即用 idempotency_key 做唯一索引插入数据库（如 PostgreSQL 的 INSERT ... ON CONFLICT DO NOTHING），成功才执行后续逻辑；失败就直接返回 409 或缓存中的原始响应体。别用内存缓存（如 Redis）单独存 key——它可能过期或被驱逐，且无法保证跨实例一致性。
- 必须用数据库主键或唯一约束兜底，不能只靠应用层判断
-
idempotency_key建议由调用方生成（如 UUIDv4），服务端只校验不生成 - 响应中要透出
X-Idempotency-Key和原始响应时间戳，方便客户端比对 - 注意 MySQL 的
INSERT IGNORE在某些版本下对 NULL 值行为不一致，优先用ON DUPLICATE KEY UPDATE显式控制
用 Flask/FastAPI 写回调接口时，如何避免重放攻击绕过幂等校验
重放攻击不是“发两次一样的请求”那么简单——攻击者可能截获请求后，改时间戳、删签名、换 header 再发一遍。单纯校验 idempotency_key 不够，必须绑定上下文。
关键是在校验幂等性前，先验证请求的时效性与完整性。比如要求 X-Timestamp 与服务端时间差 ≤ 300 秒，并用共享密钥对 method + path + body + timestamp 做 HMAC-SHA256 签名，校验 X-Signature。签名必须包含 body 原始字节（非 JSON 解析后），否则空格、换行、字段顺序变化会导致验签失败。
立即学习“Python免费学习笔记（深入）”；
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 别用
request.json参与签名计算——它会触发解析、丢弃空白、重排序键，要用await request.body()（FastAPI）或request.get_data()（Flask） - 时间戳必须用 UTC，服务端用
time.time()而非datetime.now()，避免时区歧义 - 签名密钥不能硬编码，应从环境变量或 Secrets Manager 加载，且定期轮换
- 验签失败一律返回 401，不要暴露是时间超时还是签名错——防止侧信道泄露
数据库幂等记录表设计不当引发的性能雪崩
常见错误是建一张大宽表，把所有回调参数都塞进 metadata JSON 字段，然后靠应用层查 SELECT * FROM idempotent_log WHERE key = ?。小流量没事，一旦并发上来，全表扫描+JSON 解析直接拖垮 DB。
正解是把幂等表当作“轻量锁表”来设计：只有 idempotency_key（主键）、status（success/processing/fail）、response_body（TEXT，不索引）、created_at（带索引）。所有查询只走主键，插入用 upsert，绝不模糊查询。
- 别给
response_body加索引，它只是回传用，不参与查询条件 -
status字段加索引意义不大——你不会查“所有失败的幂等记录”，只会按 key 查单条 - 如果用 MySQL，避免用
utf8mb4_unicode_ci排序规则校验 key，大小写敏感场景下可能误判，统一用utf8mb4_bin - 定期清理（如 7 天前的 success 记录），但清理语句必须带 LIMIT，防长事务阻塞
第三方支付回调（如微信/支付宝）的特殊处理点
它们的回调不走标准幂等流程：没有 idempotency_key，签名方式固定，且允许重复推送。你不能指望对方发一次就完事，必须自己识别“同一笔订单的多次通知”。
核心是提取业务唯一标识：out_trade_no（商户订单号）或 transaction_id（平台交易号），结合支付状态做状态机判断。比如微信回调里 result_code == SUCCESS 且 trade_state == SUCCESS 才算终态；若已存在相同 out_trade_no 且状态为 success，则直接返回 success XML，不执行任何业务。
- 别依赖
notify_id或回调 URL 参数做幂等——它们每次都不一样 - 微信回调 body 是 XML，支付宝是 form-urlencoded，解析时别用通用 JSON 工具，要用对应 parser
- 微信要求 5s 内返回 success XML，否则会重推，所以幂等校验必须快（DB 主键查询 + 状态判断，别加复杂逻辑）
- 支付宝回调可能带
sign_type=RSA2，验签时 openssl 版本要 ≥ 1.0.2，旧版本不支持 PSS 填充
事情说清了就结束。最常被忽略的是：幂等性不是某个函数或中间件能一劳永逸解决的，它横跨网络传输、签名验证、数据库约束、业务状态机四个层面——少一层，重放就可能漏过去。
