怎样在本地模拟 API 的 429 和断流，验证应用不会反复扣任务

本地模拟 API 的429和断流，可以验证应用失败时会不会重复完成任务，而不必对真实平台制造压力。测试要数两件事：实际请求次数和业务完成次数。它们不应混在一个“调用成功”计数里。本文附可重复运行的环回假服务与自检，全程使用合成数据。

下载并运行夹具

下载本地故障夹具，保存到专门的测试目录。使用 Python 运行：

python n036-api-fixture.py --self-test
python n036-api-fixture.py --port 8765

第一条会启动临时端口完成自检并关闭；第二条持续监听 127.0.0.1:8765，使用后按 Ctrl+C 结束。不要把监听地址改成公网。它基于标准库提供测试协议，不是生产网关，也不完整实现任一平台SDK的事件合同。

路径	合成行为	需要检查
/rate	同一测试任务前两次429，第三次成功	重试次数与上限
/cut	返回一个SSE片段后关闭，无完成标记	不应计业务完成
/bad	返回200但JSON损坏	解析失败单列
/ok	完整JSON	正常完成一次
/stats	返回各路径与任务计数	结果可复核

请求使用 X-Test-Job 传合成业务任务编号，不传真实密钥。统计是内存状态，重启服务后清零，便于重新演练；这不是生产持久化计费系统。

先确认应用确实请求了假服务

将测试环境客户端的基础地址指向环回服务，禁用真实凭据，只使用无效哨兵。检查统计中出现预期路径和任务编号，防止改错配置后仍向真实平台发送。不同SDK会自动拼接路径，必要时用适配层转换到夹具路径，不能假设它是通用的完整API替身。

对 /rate，分别验证不开重试、有限重试与重试耗尽。记录应用层与SDK层各自配置，统计实际请求数量，避免两层重试相乘。RFC允许429响应携带 Retry-After，夹具设置一秒作为测试值，客户端是否遵守需要实际观察。

失败不应触发完成副作用

在业务侧用固定任务键记录状态，只有响应完整、解析通过和业务验证通过后才进入成功。请求重试可以多次，但同一任务的完成写入应符合应用自己的幂等合同。夹具只能让你观察请求，它不能自动证明数据库事务或扣费逻辑正确。

对 /cut，即使收到200和一个文本片段，也应识别没有应用期望的完成标记，保留未完整状态。对 /bad，将协议成功与解析失败分开。测试时把真正的业务写入替换成计数器或隔离数据库，断言完成次数不会因重复请求增加。

自检与实际应用验收的边界

夹具自检验证429序列、JSON损坏、流缺完成标记和请求计数；不代表你的应用已经通过。接入应用后另存任务状态变化、请求统计与失败场景表。若应用会自动补发或用户点击重试，还需加入重复提交与并发场景。

这里没有对任何真实平台发压测，也不推导真实服务重试、计费或幂等行为。测试结果只适用于你的应用和这套明确的本地故障输入。

常见问题

200为什么仍算失败？ 可能只收到响应头或不完整内容，业务完成还需要完整性与语义校验。

假服务能证明不会重复扣费吗？ 只能验证应用自己的任务副作用，不能代替平台账单合同。

自检通过就可以发布吗？ 还要把实际客户端与业务状态接进同样场景验证。

继续处理相关问题

相关入口：OpenAI API 接入基础。

官方依据与核对日期

核对日：2026-10-23。HTTP 429 标准：429 表示过多请求，响应可包含 Retry-After；Python 测试服务：标准库可实现本地HTTP处理，官方不建议用于生产。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。