GET / POST 请求示例怎么调试：先拆四段，再按顺序排查

调试 GET / POST 示例，重点在于把示例还原成一份可复现的请求，而不是照抄一段 curl。示例只有在写清四件事时才可复现：方法加含编码的完整 URL、请求头（含鉴权与内容类型）、请求体形态、以及判定成功的响应条件。缺任何一段，出问题时都只能靠猜。

先看示例缺了哪几段#

一个最小骨架（占位值，未执行）#

下列命令中的 example.com 与 YOUR_KEY 均为占位，不是真实端点或密钥，也未实际运行。API.PLUS 的端点路径、鉴权头名称与字段定义需以其官方文档为准；本次没有可用素材，待核实。

# 未执行示例：GET，参数进查询串
curl -sS -G 'https://api.example.com/v1/items' \
  --data-urlencode 'q=hello world' \
  --data-urlencode 'page=1' \
  -H 'Authorization: Bearer YOUR_KEY'

# 未执行示例：POST，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"]}'

把密钥写进命令行会被 shell 历史和进程列表记录，实际使用应改为从环境变量读取，例如 -H "Authorization: Bearer $API_KEY"。

排查顺序：从外往里#

1. 连通性：DNS、TLS、代理与出口白名单。这一步失败时，状态码根本不会出现。
2. 状态码分类：4xx 归因于请求本身，5xx 归因于服务端或上游，3xx 先确认是否被自动跟随。
3. 响应体错误字段：多数服务会给出错误码与字段名，比猜参数快。
4. 业务参数：最后才怀疑字段取值、类型与必填项。

几个高频坑#

• curl -d 会隐式把方法改成 POST，并把 Content-Type 设为 application/x-www-form-urlencoded；想发查询串用 -G，想发 JSON 必须显式写 -H 'Content-Type: application/json'。
• 加 -L 跟随重定向时，遇到 301/302 常见客户端会把 POST 改成 GET，请求体随之丢失；需要保方法应看 307/308。这是客户端行为差异，具体到某个服务端如何返回，需实测确认。
• 查询串里的空格、&、+ 和中文都要编码，否则会被拆成别的参数。
• 同一键重复出现的处理方式未定义，不要靠"后者覆盖前者"来写逻辑。
• POST 超时后不要默认可以重试：先确认该操作是否幂等，以及服务端是否提供幂等键机制。API.PLUS 是否有此类约定，本次材料未涉及，待核实。
• 日志与工单里不要打印 Authorization 头和完整密钥，只记录前缀与请求 ID。

把"能跑通"变成"可回归"#

调通一次之后，把命令存成脚本或 .http 文件，参数走环境变量，并记录响应中的请求 ID 或 trace ID。这样下次失败时，可以判断是请求变了、数据变了，还是服务端变了——否则只能重新从第一步开始试。HTTP 语义的规范定义可参考 RFC 9110（HTTP Semantics），本文未联网核验其文本。

判断标准很简单：把示例交给另一位开发者，在不问你任何问题的前提下，他能不能发出同一条请求，并判断出成功与否。不能，就是示例还没写清。