Postman 不主动探测接口支持的 HTTP 方法，必须依据文档明确标注的 Method 字段或开发确认；发错方法会返回 405（最直接）、404 或异常响应，需通过 Status 码、Response Body 和 Allow 响应头综合判断，不可依赖 OPTIONS 请求或盲目试错。
Postman 本身不主动探测接口支持哪些 HTTP 方法，必须靠人工验证或服务端明确告知；直接发错方法会返回 405 Method Not Allowed 或 404，这是最可靠的判断依据。
看到接口文档就别猜，先查 Method 字段
绝大多数正规接口文档（Swagger、YAPI、内部 Confluence）都会在每个接口条目里明确标注 Method，比如 POST、GET、PUT。这不是可选项，是设计契约的一部分。
常见错误现象：
- 把文档写的是
POST的接口，误用GET发送，结果参数全拼在 URL 里，后端收不到body—— 返回400或空数据 - 文档写的是
DELETE，却用POST去调，后端可能静默忽略或报500
实操建议：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 打开文档时第一眼扫
Method列，不是 URL 或参数说明 - 如果文档没写，立刻找开发确认，不要靠“试出来”——这属于接口契约缺失，该补文档
- 注意有些接口对同一 URL 支持多个方法（如
/users：GET 查列表，POST 新建），此时Method就是核心区分点
OPTIONS 请求能看支持的方法，但别依赖它
HTTP 协议规定，对任意资源发 OPTIONS 请求，服务端应返回 Access-Control-Allow-Methods 响应头，列出允许的方法。但实际中：
- 很多后端（尤其 Spring Boot 默认配置）压根不实现
OPTIONS处理逻辑，直接404或501 - 即使返回了，也可能是预设的宽泛值（如
GET, POST, PUT, DELETE），不代表当前接口真实可用 - CORS 场景下浏览器自动发的
OPTIONS是预检请求，和你手动发的语义不同，响应头也可能被网关过滤
实操建议：
- 在 Postman 中新建一个请求，
Method选OPTIONS，URL 填目标地址，点Send - 只当响应头里真有
Access-Control-Allow-Methods且值合理时，才作参考 - 绝不能跳过文档或开发确认，仅凭
OPTIONS结果就断定“这个接口支持 PATCH”
发错方法时的典型响应要立刻识别
Postman 不会警告你“这个方法可能不对”，它只忠实地发出去并展示响应。你需要盯住三处：
-
Status码：405 Method Not Allowed是最直接证据；404有时也意味着路由没配该方法；200但返回空或异常数据，可能是后端降级处理，不能算支持 -
Response Body内容：有些后端会在405时返回 JSON 提示，如{"error":"Only POST allowed"} -
Response Headers：检查是否有Allow头（RFC 标准字段），例如Allow: GET, HEAD—— 这比OPTIONS更可信，但依然少见
实操建议：
- 对一个新接口，快速轮发
GET/POST/PUT/DELETE，观察哪几个返回405，记录下来 - 如果
GET和POST都返回200，但业务逻辑明显不对（比如 POST 返回了列表），说明后端没做方法校验，属于缺陷，要提 BUG - 别信“能发出去就代表支持”——
GET发过去服务器没崩，不等于它按预期处理了你的意图
批量验证多个方法？用 Postman 的 Tests 脚本辅助
如果你真需要自动化验证某 URL 支持哪些方法（比如做 API 合规扫描），可以写简单脚本，但要注意它只是辅助手段：
在任意一个请求的 Tests 标签页里粘贴：
pm.test("Check if method is allowed", function () {
const status = pm.response.code;
const method = pm.request.method;
if (status === 405) {
console.log(`❌ ${method} not allowed`);
} else if ([200, 201, 204].includes(status)) {
console.log(`✅ ${method} accepted`);
}
});
然后复制多个请求，分别改 Method 和 URL，再用 Collection Runner 批量跑。但注意：
- 这不能替代文档和沟通，只是帮你快速暴露问题
- 某些方法（如
TRACE、CONNECT）可能被 WAF 或 Nginx 拦截，返回403或超时，和接口本身无关 - 生产环境慎用，避免触发风控或日志告警
真正容易被忽略的点是：很多团队把“接口支持什么方法”当成隐性知识，写在代码注释或口头约定里。Postman 测试的第一步，永远不是点 Send，而是确认这个契约是否已显性化、可追溯。
