GET / POST 请求示例怎么调试：把一次请求拆成可核对的四层
调试 GET / POST 示例的关键，是把请求拆成方法、URL 与查询串、请求头、请求体四层，逐层固定变量定位偏差；查询参数用工具编码、POST 先确认 Content-Type 与体格式，再用状态码分层缩小范围。API.PLUS 的具体端点、鉴权与字段定义本次材料未提供，待核实。
- 把请求拆成方法、URL、请求头、请求体四层，比整体替换示例更快定位错误。
- GET 的查询参数交给 curl -G --data-urlencode 编码，用 -v 核对实际发出的 URL。
- POST 先确认 Content-Type 与请求体格式一致，再看状态码；415 通常指向这一层。
调试 GET / POST 请求示例，重点不在于把示例照抄一遍，而在于把一次请求拆成方法、URL 与查询串、请求头、请求体四层，逐层固定变量：哪一层与接口文档不符，错误通常就落在哪一层。下文的命令与请求体都是演示写法，未在本次写作中执行，也不指向任何已核验的线上端点。
API.PLUS 各接口的具体路径、鉴权方式、字段类型与错误码含义，本次材料没有提供，待核实，请以官方文档为准。下面只讨论不依赖具体平台的通用调试方法。
一、四层拆分：先定位，再改参数#
- 方法：GET 按 HTTP 语义是安全、幂等的读取操作，POST 用于提交；二者的差别不只是动词不同。
- URL 与查询串：协议、主机、路径、查询参数各自独立，路径大小写与末尾斜杠常被忽略。
- 请求头：鉴权头、Content-Type、Accept 影响服务端如何解析与鉴权。
- 请求体：只对允许带体的方法有意义；JSON 语法错误会让请求在解析阶段就失败，还没进入业务校验。
二、GET 示例：把编码交给工具#
查询参数一旦出现空格、中文、& 或 =，手工拼接最容易出错。用 curl 的 -G 配合 --data-urlencode 生成编码后的 URL，再用 -v 打出实际发出的请求行，能直接看出参数是否被截断或重复编码。
# 演示写法，未执行
curl -v -G 'https://example.com/api/items' \
--data-urlencode 'q=关键词' \
--data-urlencode 'page=1' \
-H 'Accept: application/json'核对 -v 输出的请求行，比反复改代码更快。若接口需要鉴权头，先用占位值确认请求形态，再替换为真实凭证；不要把真实密钥写进示例、日志或截图。示例中的 example.com 是占位域名。
三、POST 示例：先确认体格式#
POST 的两类高频故障是 Content-Type 与请求体实际格式不匹配，以及 JSON 未正确转义。把请求体放进文件、用 -d @file 提交，可以绕开 shell 引号带来的干扰。
// body.json，占位示例
{
"name": "demo",
"count": 1
}# 演示写法，未执行
curl -v -X POST 'https://example.com/api/items' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer YOUR_KEY' \
-d @body.jsonYOUR_KEY、字段名与路径均为占位，不代表任何真实接口。
四、用状态码做分层定位#
状态码先告诉你失败发生在哪一层，再去查具体字段，能少走很多弯路。
| 状态码 | 一般含义 | 先核对什么 |
|---|---|---|
| 400 | 请求语法或参数不合法 | JSON 语法、字段类型 |
| 401 | 未认证或凭证无效 | 鉴权头是否发出、是否过期 |
| 403 | 已认证但无权限 | 账号权限范围 |
| 404 | 路径或资源不存在 | 路径拼写、末尾斜杠、大小写 |
| 405 | 该路径不接受此方法 | 文档要求 GET 还是 POST |
| 415 | 媒体类型不被支持 | Content-Type 与请求体格式 |
| 429 | 请求过多 | 限流规则，不要盲目重试 |
| 5xx | 服务端侧问题 | 保留请求 ID 与时间点，再排查 |
上表是 HTTP 规范中的一般定义（可对照 RFC 9110）。不少接口会借用 422 表示语义校验失败，这类约定不在规范强制范围内，要以目标接口文档为准，本文不代为推断。
五、实战核对顺序#
- 用
-v或调试代理确认最终发出的方法、URL、请求头与请求体，而不是看代码里“以为”发出的内容。 - 先让鉴权和路径通过（不再返回 401、404、405），再调试字段，避免两类问题互相掩盖。
- 把变量减到最小：一次只改一个参数，确认响应差异确实由它引起。
- 记录状态码、响应体与请求 ID；出问题时，这份记录比“上次好像可以”有用得多。
- 对超时与 429、5xx 的自动重试要单独设计，GET 与 POST 的重试安全性不同，不能套用同一策略。
六、边界：示例证明不了什么#
示例只能说明“请求长什么样”，不能说明“服务端会怎么处理”。限流阈值、幂等保证、超时与重试语义都属于接口契约，需要单独核对文档，或用有记录、有环境的实测来支撑。本文未运行任何请求，因此不给出任何响应示例、耗时段或成功率数字。
至于 API.PLUS 是否对 GET / POST 有额外约定（例如签名头、必填字段、错误码细分），本次材料未提供，待核实；在拿到官方文档前，不宜据本文推断该平台的任何具体行为。
