GET 与 POST 请求的调试与实战：先分清参数位置、副作用与重试边界
调试 GET 与 POST 的关键不在方法名，而在三件事：参数放在 URL 还是请求体、请求有没有副作用、失败后能否安全重试。GET 侧重点是查询串编码、缓存命中与日志暴露；POST 侧重点是 Content-Type 与请求体编码是否匹配，以及重试会不会造成重复创建。本文示例均为占位路径且未执行，API.PLUS 的具体端点、鉴权与错误码待核实。
- 判断一个接口该用 GET 还是 POST，看它是否改变服务端状态；这直接决定它能否被缓存、被预取、被自动重试。
- POST 报 400 或服务端收到空对象时，先核对 Content-Type 与请求体编码是否一致，再查字段名。
调试 GET 与 POST，先分清三件事：参数放在哪里、这次请求有没有副作用、失败之后能不能安全重试。这三件事决定了你该看哪一段日志、在哪个环节复现问题，也决定了同一个 bug 在本地能否重现。下面按这个顺序展开。
先说范围。本文没有 API.PLUS 的接口文档，因此不给出任何具体端点、鉴权方式、限流阈值或错误码；示例统一使用 api.example.com 与占位路径，均为未执行的示意，YOUR_KEY 为占位密钥。实际接入请以官方文档为准。
方法语义决定调试重点#
HTTP 语义规范（RFC 9110）把 GET 归为「安全」方法：它不应当改变服务端状态；POST 没有这个承诺。由此派生出两个工程后果。其一，GET 的响应可能被浏览器、CDN 或反向代理缓存，也可能被预取。其二，POST 在超时后被客户端或网关自动重试时，可能重复创建资源。这两点在排查时经常被误判成“接口不稳定”。
GET 调试：编码、缓存、日志#
查询串编码
空格、中文、& 与 = 都必须编码，否则服务端拿到的是被截断的值。数组和嵌套对象没有统一写法：tags=a&tags=b、tags[]=a、tags=a,b 都可能出现，具体取决于服务端框架。遇到“参数丢了”，先怀疑这一层，而不是先怀疑网络。
缓存干扰
调试时为绕开缓存随手加时间戳参数，会让缓存键每次都不同，反而看不出真实缓存行为。更可靠的做法是读响应头里的 Cache-Control 与 ETag，并观察是否出现 304。
日志暴露
查询串通常会完整写进访问日志、代理日志与浏览器历史。令牌、手机号一类信息不宜放在 URL 中——这也是把密钥留在服务端的原因之一。
# 未执行示例，仅示意参数位置；域名与路径为占位
curl -sS -G 'https://api.example.com/v1/items' \
--data-urlencode 'q=机械键盘' \
--data-urlencode 'page=1' \
-H 'Accept: application/json'POST 调试：先看 Content-Type#
服务端按 Content-Type 决定如何解析请求体。头里声明 application/json、体里发的却是表单编码，常见结果是 400，或者服务端收到一个空对象。-d 默认按表单发送，用 JSON 必须显式声明头。三种常见类型：
application/json：体是 JSON 文本，注意字符转义与 UTF-8 编码。application/x-www-form-urlencoded：键值对，编码规则与查询串相同。multipart/form-data：含文件时必须使用，边界串由客户端生成。
重试与幂等
建议对会产生资源的 POST 在客户端生成幂等键随请求发送，由服务端去重；重试只针对明确的网络错误或 5xx，并带退避。这是工程实践建议，服务端是否支持幂等键属于待核实项，需查对接文档。
# 未执行示例，仅示意请求体编码；YOUR_KEY 为占位
curl -sS -X POST 'https://api.example.com/v1/items' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer YOUR_KEY' \
-d '{"name":"demo","tags":["a","b"]}'两类请求的对照#
| 关注点 | GET | POST |
|---|---|---|
| 参数位置 | URL 查询串 | 请求体，也可带查询串 |
| 是否进访问日志 | 查询串通常进日志 | 请求体通常不进日志 |
| 缓存 | 可被缓存或预取 | 默认不缓存 |
| 自动重试 | 语义上安全，仍可能重复计费 | 可能造成重复创建 |
| 调试重点 | 编码与缓存命中 | Content-Type 与体编码 |
一个可复用的排查顺序#
- 确认方法与副作用：这个操作会不会改服务端状态？据此判断能否重试。
- 看请求行与请求头：方法、路径、
Accept、Content-Type、鉴权信息放在头还是查询串。 - 看参数位置与编码：GET 查查询串，POST 查请求体，注意转义。
- 看响应：状态码、响应体结构、响应头中的缓存与限流相关字段。
- 与服务端日志对齐时间点，确认请求是否真的到达，以及在哪个环节被拒绝。
本文未覆盖 API.PLUS 的具体接口行为。若官方文档给出了鉴权位置、限流规则与错误码表，应以文档为准，并把这些信息补进上面的排查顺序。
