拿到 GET/POST 示例之后：先复现请求，再改参数
调试 GET/POST 示例时，应先原样复现一次，再用“一次只改一个变量”的方式逐项加参数；GET 的常见问题在查询串编码，POST 的常见问题在 Content-Type 与请求体是否一致；状态行、响应头、响应体要分层核对，一次跑通不等于接口约定已经明确。API.PLUS 的基址、鉴权头、错误体字段等具体约定本次无材料，需按官方文档核实。
拿到一段 GET 或 POST 示例后，第一件事不是修改参数，而是原样跑通一次，确认“方法 + 路径 + 头 + 体”能换来一个可解释的响应。API.PLUS 的基址、鉴权头名称、错误体字段本次没有可核验材料，下面涉及具体字段的地方一律用占位；接入前请以官方文档为准。
为什么 GET 与 POST 的调试重点不同#
GET 把参数放在 URL 查询串里，出错多集中在编码与拼接：空格、中文、&、同名重复键、超长 URL，以及参数被完整写进访问日志。POST 把数据放在请求体里，出错多集中在“声明”与“内容”不一致：Content-Type 写 application/json 却发了表单串，或反过来；也有人把同一个参数同时塞进查询串和 body，而服务端只读其中一处。这是协议层面的通用差异，具体服务端如何取舍取决于实现，不能凭示例推断。
复现顺序：一次只改一个变量#
- 固定目标：从文档抄下方法、路径与必需的头，先不改任何参数值。
- 发最小请求：只保留一个必需参数或一个最小 body，跑通再扩张。
- 记录完整交换：保留状态行、响应头与响应体，不要只看终端里打印出来的那段 JSON。
- 逐项加回：每加一个参数就重跑一次，出问题时能立刻定位到是哪一次改动引起的。
- 固化基线：把跑通的请求存成脚本或
.http文件，作为后续对照。
两个对照示例#
# 未执行的示例：域名、路径、参数名与键值均为占位
curl -sS -i "https://api.example.com/v1/items?limit=10" \
-H "Authorization: Bearer YOUR_KEY"-i 表示连同响应头一起输出。Content-Type、请求 ID 这类信息常出现在头部，只看 body 会丢掉它们。
# 未执行的示例
curl -sS -i -X POST "https://api.example.com/v1/items" \
-H "Authorization: Bearer YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"name":"demo"}'上面两条命令的输出、状态码与错误体内容都未经运行验证。若把 -d 的数据换成表单串，必须同时把 Content-Type 改成 application/x-www-form-urlencoded；两者不匹配时，服务端可能读不到预期的字段。
响应该分三层看#
| 层次 | 看什么 | 常见误判 |
|---|---|---|
| 状态行 | 4xx 与 5xx 的责任划分 | 把 401/403 当成参数错误，反复改参数 |
| 响应头 | Content-Type、请求 ID、限流相关字段（字段名待核实） | 只复制 body，丢掉可用于排查的 ID |
| 响应体 | 是成功数据还是错误对象 | 用 HTTP 200 判定成功，忽略体内错误信息 |
边界：一次跑通不等于契约明确#
一次成功只能说明“这一组输入在这个时间点得到了这个输出”。参数取值范围、错误码全集、限流与重试语义、请求是否幂等，都需要另找依据。API.PLUS 的鉴权方式、错误体结构、是否提供请求 ID 与限流头，本次材料均未提供，属待核实项；不要从示例反推这些约定，也不要因为示例返回 200 就认为可选参数的缺省行为已经确定。
调试记录建议保留四项：完整请求、完整响应、发生时间、当时的输入参数。有了这四项，“时好时坏”的问题才有可能变成可复现的对照。
