GET 与 POST 示例调试：把请求、响应和错误体分开核对

调试 GET/POST 示例，先别急着换工具。更有效的做法是把一次调用固定成可复现的最小请求，再逐层增加变量：方法、URL、请求头、请求体、响应。本文以 API.PLUS 接入为背景，但不假设具体端点、鉴权、配额或错误码；这些应以对应接口文档为准（待核实）。

先分清方法承载什么#

在常见 HTTP API 中，GET 把筛选、分页等参数放在查询字符串里，适合读取资源；POST 通常把提交内容放在请求体里，适合创建或触发处理。不要把“GET 一定安全、POST 一定不安全”当成业务结论：是否幂等、是否改变状态，要看接口契约。GET 携带请求体在部分客户端、代理和服务器上支持情况可能不一致，调试时不要依赖这条路径。

按层核对，而不是一次性拼完整请求#

1. 先记录完整请求：方法、完整 URL、请求头、请求体、时间与客户端版本。
2. 用最小参数发一次请求，确认网络、TLS、鉴权和路由能通。
3. 每次只加一个变量，例如一个查询参数、一个请求头或一个字段，观察响应变化。
4. 对照响应状态码、Content-Type 与响应体，分别判断传输层、协议层和业务层错误。

两个未执行的最小示例#

下面仅演示请求结构，均未实际执行；api.example.com 与 YOUR_KEY 是占位符，不能当作真实 API.PLUS 端点或密钥。

curl -i 'https://api.example.com/v1/items?limit=2' \
  -H 'Authorization: Bearer YOUR_KEY'

curl -i -X POST 'https://api.example.com/v1/items' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  --data '{"name":"demo"}'

GET 示例重点看查询参数是否被正确编码、鉴权头是否到达服务端；POST 示例重点看 Content-Type 与实际请求体是否一致。若服务端返回 4xx，先保留原始响应，不要只记录“失败”。

响应要分成功体和错误体#

不要用状态码 200 直接推断业务成功。先看状态码，再看响应头中的内容类型，最后按契约解析响应体。成功体和错误体可能结构不同：错误体可能是 JSON，也可能是 HTML 或空响应。日志中记录请求 ID、状态码和脱敏后的错误摘要；不要记录完整密钥、Cookie 或用户隐私数据。API.PLUS 的具体错误码和重试规则需查对应文档（待核实）。

常见误区#

• 把 GET 参数直接拼进 URL 却不做编码，空格、中文和保留字符会改变语义。
• POST 发了 JSON，却漏掉 Content-Type: application/json。
• 只比较响应正文，忽略状态码、响应头和重定向。
• 把一次成功调用当成稳定结论；没有可复现记录，就无法区分偶发网络问题与契约错误。

结论#

GET/POST 示例调试的核心，是让请求可复现、变量可分离、响应可解释。先固定最小请求，再逐层加参数；先核对协议层，再判断业务层。没有实际执行记录时，示例只能作为结构参考，不能写成实测结论。