GET 与 POST 请求的调试与实战：先固定四要素，再看响应
调试 GET 与 POST 的差别不在工具，而在方法语义：GET 是安全方法、可重放，POST 不承诺幂等，重发前要先确认副作用。文章给出构造请求的四要素（方法路径、请求头、参数位置、请求体）、调试顺序、未执行的 curl 示例，以及 GET 带体、Content-Type 错配、重试与日志泄露等边界；涉及 API.PLUS 端点的具体细节均标为待核实。
调试 GET 与 POST 请求，要固定的其实是四件事：方法语义、请求头、请求体格式，以及一个能复现问题的最小示例。抓包工具和命令行客户端只是把这几件事显示出来。本文给的是通用调试方法，不涉及任何线上端点的实测；示例中的域名与密钥都是占位符。
一、方法语义决定调试策略#
按 HTTP 语义规范（RFC 9110，本次未联网核验原文），GET 被定义为安全方法：它不应改变服务端状态，因此可以放心重放、可以被缓存，参数通常放在查询串里。POST 既不是安全方法，也不承诺幂等（idempotent，指同一请求重复执行与执行一次的效果相同）：同一条请求连发两次，服务端可能创建两条记录。
这条差异直接决定调试动作。GET 出问题时重发一次几乎没有代价；POST 出问题时，先要回答"上一次是否已经产生副作用"，再决定是否重试。
二、构造示例前先固定四要素#
| 要素 | GET 的关注点 | POST 的关注点 |
|---|---|---|
| 方法与路径 | 参数是否已编码进查询串 | 路径是否指向集合或动作 |
| 请求头 | Accept、Authorization | 额外需要 Content-Type 与 Content-Length |
| 参数位置 | 查询串 | 请求体（JSON 或表单） |
| 请求体 | 通常为空 | 结构与编码必须和 Content-Type 一致 |
四要素里最容易漏的是"参数位置"：把本该放在请求体里的字段拼到查询串，服务端往往返回一个看似无关的校验错误，把排查引向错误方向。
三、按顺序看，而不是一次看全部#
- 先看请求行：方法拼写、路径、查询串是否与预期一致。
- 再看请求头：鉴权头是否带上、Content-Type 是否与体匹配。
- 然后看请求体：是否有值、是否被转义两次、是否为空字符串。
- 接着看响应状态码与响应头：重定向、缓存、限流提示常藏在头里。
- 最后才读响应体：错误信息是否指向具体字段。
顺序的价值在于排除：前一步没确认，后一步的现象就无法归因。
四、未执行的示例#
以下命令按 GNU/Linux 下的 bash 与 curl 书写，本次未执行，其中的输出只是预期的形式示意，不是实际结果。域名 example.com 与 YOUR_KEY 均为占位。
# GET：参数放查询串，只读取，可安全重放
curl -sS -i "https://example.com/api/items?page=1&size=20" \
-H "Accept: application/json" \
-H "Authorization: Bearer YOUR_KEY"
# POST：显式声明 Content-Type，体与声明保持一致
curl -sS -i -X POST "https://example.com/api/items" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_KEY" \
-d '{"name":"demo","note":"占位数据"}'把 -i 留下，是因为响应头里的信息常常比响应体更能说明问题；调试结束后再去掉它，避免把完整的鉴权头写进共享日志。
五、几个容易踩的边界#
- GET 带请求体：规范没有禁止，但语义未定义，不少网关会直接丢弃。依赖它属于未定义行为。
- URL 长度：上限由服务端与中间层决定，具体阈值待核实，不要把大段数据塞进查询串。
- Content-Type 与实际体不一致：服务端可能解析出空对象，报错信息却指向字段缺失。
- 重试 POST：需要幂等键之类的机制，是否支持取决于具体服务，待核实。
- 日志泄露：把完整 URL 打出来，等于把查询串里的密钥写进日志。
六、涉及 API.PLUS 时的边界#
本文没有调用 API.PLUS 的任何端点，也没有核验其文档。接入前需要自行确认：鉴权头的名称与形式、哪些操作适合用 GET 或 POST、错误码与限流口径、是否提供幂等机制。这些项目前均标为待核实，不应从上面的通用示例推断其具体行为。
可复用的只有方法本身：先用一个最小 GET 确认鉴权与网络链路通，再用一个字段最少的 POST 确认写入路径通，两次都保留原始请求与响应，作为后续对照的基线。
