API.PLUS 的 GET 与 POST 请求示例调试：先定方法与载荷，再排查失败路径
调试 GET/POST 示例的关键是确认方法与载荷位置，用真实请求逐项复现，并分别排查状态码、CORS、重定向、编码和重试语义；具体接口细节待核实。
- 先抓真实请求：方法、URL、请求头、请求体和响应状态缺一不可。
- GET 的查询参数通常在 URL 查询串，POST 的业务载荷通常在请求体，解析方式由 Content-Type 决定。
- /403、404、405、415、CORS 预检、重定向和重试语义是常见失败点；API.PLUS 的具体端点与限额待核实
调试 API.PLUS 的 GET/POST 示例，先确认请求把数据放在哪里：GET 的查询参数通常在 URL 查询串，POST 的业务载荷通常在请求体，请求体如何解析由 Content-Type 决定。没有真实的方法、URL、请求头、请求体和响应状态，示例就只能靠猜。本文不引用具体 API.PLUS 端点；路径、鉴权头、参数名和限额需以官方文档为准（待核实）。
先分清 GET 和 POST 的调试面#
| 检查项 | GET | POST |
|---|---|---|
| 数据位置 | 查询串或路径参数 | 请求体为主，查询串也可有过滤参数 |
| 请求体 | 通常没有；不要依赖 GET body | 常见 JSON 或表单 |
| 重试 | 语义上安全、幂等，仍要看服务端行为 | 默认不保证幂等，需幂等键或业务去重 |
| 敏感数据 | 可能进入日志和历史记录 | 放请求体更合适，但仍需 HTTPS |
用可复现的命令抓真实请求#
下面的命令是未执行示例，域名、路径和密钥均为占位。请替换为文档中的真实地址，不要把生产密钥写进命令历史。
curl -v --get 'https://api.example.com/v1/items' \
--data-urlencode 'limit=20' \
-H 'Authorization: Bearer YOUR_KEY' \
-H 'Accept: application/json'curl -v -X POST 'https://api.example.com/v1/items' \
-H 'Authorization: Bearer YOUR_KEY' \
-H 'Content-Type: application/json' \
--data '{"name":"demo","enabled":true}'若文档要求表单提交，把 Content-Type 改为 application/x-www-form-urlencoded，用 --data-urlencode 传字段，不要手工拼接 & 和未编码的值。浏览器中则在 Network 面板核对 Request Method、Request URL、Request Headers、Payload/Form Data 与 Response，不要只看 Console。
常见失败按层拆#
- 状态码：400 常见于参数或 JSON 语法错误，401/403 指向鉴权或权限，404 查路径，405 查方法，415 查
Content-Type。错误体通常比状态码更有信息量。 - 跨源资源共享（CORS）：带
Authorization或 JSONContent-Type的浏览器请求常触发预检；先看 OPTIONS 是否成功，以及响应是否允许来源、方法和请求头。 - 重定向：301/302 可能让部分客户端把 POST 改成 GET；要保留方法和请求体时，检查 307/308 及客户端实际行为。
- 编码：查询值要 URL 编码；JSON 必须合法；表单体用
&连接并编码，不要拼接未转义的值。 - 重试：POST 默认不保证幂等，重复执行可能产生重复写入；只有接口明确支持幂等键，或业务能去重时才重试。
从最小例开始加变量#
先用一个无业务参数的 GET 确认网络与鉴权，再加一个查询参数；换成 POST 时只保留必填字段，最后加可选字段、分页和排序。每加一项就对比状态码、Content-Type 和错误体。不要一次复制完整示例后同时改 URL、请求头和 body，否则无法判断是哪一层出错。
一次调试记录至少留下：方法、最终 URL（含重定向后）、脱敏后的请求头、请求体、状态码、响应头中的 Content-Type/Cache-Control/请求 ID，以及响应体前若干字节。
边界#
API.PLUS 的具体 URL 长度上限、POST 体积上限、超时、限流和错误码，需查官方文档或实际响应头，不能用通用经验代替。GET 是否允许请求体、POST 是否支持幂等键，也应以接口契约确认。
