GET 与 POST 请求示例怎么调试：从拼参数到核对响应

调试一个 GET 或 POST 请求，真正的工作不是“点到能通”，而是把请求拆成可复核的部件：方法与 URL、查询串、请求头、正文编码，以及响应的状态码与业务错误。下面给的是通用调试方法。文中的请求示例为未执行的示例，域名、密钥均为占位（example.com、YOUR_KEY）；API.PLUS 的具体路径、鉴权方式和限额本次没有可核验材料，需以官方文档为准（待核实）。

一次请求的五个可核对部件#

• 方法与 URL：路径是否拼错、末尾斜杠是否敏感、是否误用了正式环境的域名。
• 查询串：参数名大小写、数组与嵌套对象的写法、空值如何表示。
• 请求头：鉴权头格式（如 Bearer 前缀有无空格）、Accept、Content-Type。
• 正文：实际发出的字节是否符合声明的编码，是否被客户端库二次序列化。
• 响应：状态码、响应头（如请求追踪 ID、限流字段）、正文错误结构。

GET：参数交给工具编码，不要手拼字符串#

查询串常见的失败原因是手工拼接：空格、中文、&、+ 都会改变参数边界。用工具的编码能力更稳妥：

# 未执行的示例，命令仅示意参数写法
curl -sS -G 'https://api.example.com/v1/items' \
  --data-urlencode 'q=状态 正常' \
  --data-urlencode 'page=1' \
  -H 'Authorization: Bearer YOUR_KEY'

-G 把数据放进查询串而不是正文，--data-urlencode 负责百分号编码。若换成浏览器里的 URLSearchParams 或语言自带的 URL 构造器，道理相同：让库决定编码，人只负责键值。

POST：Content-Type 决定服务端怎么读正文#

同一段内容，声明成不同编码，服务端的解析路径不同。发送 JSON 与发送表单是两件事：

# 未执行的示例：JSON 正文
curl -sS -X POST 'https://api.example.com/v1/items' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"name":"demo","tags":["a","b"]}'

# 未执行的示例：表单正文
curl -sS -X POST 'https://api.example.com/v1/items' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -d 'name=demo&tags=a'

curl 的 -d 默认声明 application/x-www-form-urlencoded，所以表单示例无需再写这一行；而发 JSON 时必须显式声明 application/json，否则服务端可能按表单去解析一段 JSON 文本，得到的字段自然是空的。排查“参数明明传了却没生效”时，这一条应优先检查。

调试顺序：先定位层级，再改代码#

1. 用 curl -i 或 -v 看清实际发出的请求行、请求头，以及返回的状态码与响应头。
2. 先判断状态码属于哪一层：4xx 多为请求本身的问题（路径、鉴权、参数、编码），5xx 多为服务端问题，与参数细节关系不大。
3. 状态码正常但结果不对时，读响应正文里的业务错误字段和错误消息，不要只看 HTTP 状态。
4. 最后才回到客户端代码，确认框架有没有改写 URL、追加默认头、或把已序列化的字符串再序列化一次。

容易误判的几处边界#

• 200 不等于业务成功：部分接口在正文内返回业务错误码，需按文档判断，不能以状态码为唯一依据。
• GET 带正文不可依赖：HTTP 语义标准 RFC 9110 没有禁止，但也没有为 GET 正文定义通用语义，中间层处理不一致，参数应放查询串或改用 POST。
• 重试要看幂等性：POST 通常非幂等，网络超时后直接重试可能产生重复写入。是否支持幂等键，需按具体接口文档确认（待核实）。
• 日志要脱敏：调试时打印完整请求头会把 Authorization 写进日志，建议只记录方法、路径、状态码与追踪 ID。

GET 与 POST 的关注点对照#

把上面几项写成一次可重放的核对清单，比记住某个具体接口的报错更有用：换一个平台、换一个端点，需要检查的还是这几处。