GET/POST 调试的交付物：请求契约、证据字段与重试判定
调试 GET/POST 示例时，应先固定请求契约，记录可复现的请求与响应证据，再根据接口语义和副作用决定是否重试。API.PLUS 的具体端点、认证与限流规则在本次材料中未提供，需另行核实。
面向 API.PLUS 的接入调试，GET/POST 示例的交付物不只是“请求成功”，而是三件事：可复现的请求契约、可核对的响应证据、可判定的重试边界。本次材料没有提供 API.PLUS 的端点、认证头、参数名和错误体，因此下面不写具体接口，只说明通用调试方法；涉及 API.PLUS 的实际字段与限制，需以可核验文档为准（待核实）。
先把请求契约写成一张表#
建议在发请求前，把方法、URL、参数位置、请求头、body 编码和预期响应写成表。表中的 api.example.com 与 YOUR_KEY 是占位，不是 API.PLUS 真实地址或密钥。
| 检查项 | GET 常见做法 | POST 常见做法 | 建议留存的证据 |
|---|---|---|---|
| 参数位置 | 放 URL 查询串，注意编码 | 放 body，字段名与文档一致 | 脱敏 URL、字段名、字段长度 |
| Content-Type | 通常不发送 body | JSON 或表单需与 body 一致 | 请求头实际值 |
| 认证 | 按文档放入请求头 | 同左，不写入日志 | 认证方案名，不记录密钥 |
| 重试判断 | 仍需确认接口是否幂等 | 未确认幂等键前不自动重试 | 状态码、错误体、request-id |
用最小示例确认参数位置#
下面两个 curl 示例只用于演示“查询参数在 URL、提交数据在 body”的差异，未实际执行，输出不能当作实际结果。API.PLUS 的真实路径和认证方式待核实。
curl -sS -X GET 'https://api.example.com/v1/items?limit=20' \
-H 'Authorization: Bearer YOUR_KEY' \
-H 'Accept: application/json'
curl -sS -X POST 'https://api.example.com/v1/items' \
-H 'Authorization: Bearer YOUR_KEY' \
-H 'Content-Type: application/json' \
-d '{"name":"demo"}'如果 POST 发送 JSON，Content-Type 与 body 要一致；发送表单时使用 application/x-www-form-urlencoded。把 YOUR_KEY 换成真实值前，先确认 API.PLUS 文档要求的认证方案；不要把密钥写进文章、日志或截图。
记录能复现问题的证据#
- 请求侧：方法、脱敏 URL、查询参数名、Content-Type、Accept、认证方案名、body 字段名与长度。
- 响应侧：状态码、响应 Content-Type、响应体摘要、request-id 或 trace-id、耗时。
- 环境侧：调用时间、客户端版本、是否经过代理；这些信息有助于区分网络问题和接口问题。
推断：如果同一组参数在不同时间得到不同结果，先保留 request-id 和响应体，再判断是参数错误、鉴权问题还是服务端临时失败；不要仅凭状态码猜业务原因。
重试边界要按副作用判断#
建议把“连接失败”“已收到 4xx”“已收到 5xx”“超时但可能已提交”分开处理。GET 示例通常用于读取，但仍需确认接口文档是否声明幂等；POST 示例可能产生副作用，未确认幂等键或去重机制前，不应自动重试。对 429 或 5xx 是否重试、重试几次、是否遵守 Retry-After，均应以 API.PLUS 文档和实际错误体为准（待核实）。
可复现的调试记录，应能让另一位开发者用同样的方法、脱敏参数和预期响应复现问题；不能把占位示例的输出当成实测结果。
上线前的检查#
把调试通过的示例收敛成契约测试：固定参数位置、Content-Type、成功状态码和错误体结构；对日志做脱敏；对 POST 增加幂等键或人工确认流程（若接口支持）。API.PLUS 的实际认证、限流、错误码和响应字段本次未提供，不能据此承诺可用性或性能。
