GET / POST 请求示例怎么调试：从构造到复核的开发者清单

调试 GET 与 POST 请求，核心只有一件事：把“请求是否按预期发出”和“服务端是否正确处理”拆成两段，分别验证。只盯着状态码，会把这两类失败混成一类。本文没有 API.PLUS 的接口文档材料，因此端点路径、鉴权方式与配额一律待核实；示例统一使用 example.com 占位域名与 YOUR_KEY 占位密钥，均为未执行的示例，不对应任何真实服务。

先把失败分成四类#

• 构造错误：查询参数未编码、请求头与 body 编码不一致、必填字段拼写错误。
• 传输失败：DNS、TLS 握手、连接超时、读取超时，通常没有 HTTP 状态码。
• 语义失败：拿到 4xx/5xx，说明请求已到达并被处理，问题在参数、凭证或服务端。
• 解析失败：客户端把错误响应当成功结构解析，报错位置与真实原因相距很远。

这四类的观察点不同。没有状态码时先查网络与超时，有状态码时再查参数与鉴权，顺序颠倒会白花时间。

GET：不要手工拼查询串#

查询参数里出现空格、&、中文时，手工拼接几乎必然出错；& 在 shell 中还需要引号。用工具代为编码，可以让“我写了什么”和“实际发出什么”保持可核对。

# 未执行示例，curl 版本待核实
curl --max-time 10 --trace-ascii trace.txt \
  -G 'https://api.example.com/v1/items' \
  --data-urlencode 'q=hello world' \
  --data-urlencode 'page=1' \
  -H 'Authorization: Bearer YOUR_KEY'

-G 把后续的 --data-urlencode 内容转成查询串，--trace-ascii 把实际发出的请求行与请求头写入文件。排错时以 trace 为准，不以自己写的命令行为准。

POST：先定 Content-Type，再定 body#

JSON 与表单是两种不同编码，服务端通常按 Content-Type 解析。请求头声明 JSON、body 却是表单编码时，得到的 4xx 往往与参数本身无关，容易误判成字段错误。

# 未执行示例
curl --max-time 15 --trace-ascii trace.txt \
  -X POST 'https://api.example.com/v1/items' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  --data-binary '{"name":"demo"}'

用 --data-binary 而非 -d 的表单编码默认行为，可避免 body 被改写。若该 POST 有副作用且需要重试，应使用由客户端生成、在多次重试间保持不变的幂等键；字段名与是否支持，以官方文档为准（本次材料未提供，待核实）。没有幂等保证时，超时后重试可能产生重复写入。

GET 与 POST 在调试上的差异#

推荐的排错顺序#

1. 用最小请求确认通路：只带一个必填参数，确认能拿到非网络类响应。
2. 逐个补参数，找到触发失败的那一个，而不是一次改多处。
3. 对比 trace 中实际发出的请求行、请求头与预期差异。
4. 最后再怀疑服务端；保留响应中的请求标识与本地时间戳，便于对时。

记录什么才算可复核#

• 请求方法与完整 URL（密钥打码，只留前缀）。
• 关键请求头：Content-Type、鉴权头类型；不要记录完整凭证。
• 状态码、响应体截断片段、总耗时与重试次数、幂等键取值。
• 运行环境与工具版本，否则同样的命令在别处可能表现不同。

对 API.PLUS 的调用同样适用上述流程，但具体路径、认证形式、错误码含义与限额要求，本次材料未提供，需以官方文档核对后再写入调试脚本。