服务器是否支持特定cors动词（如put、delete、patch）取决于预检响应中access-control-allow-methods头是否明确包含该动词；需通过浏览器network面板查看options请求的响应头，或用curl -i -x options手动验证，同时注意credentials与origin的联动限制。
检测服务器是否支持特定 CORS 动词（比如 PUT、DELETE、PATCH），本质是验证服务端是否在预检响应（OPTIONS）中明确声明了该方法——因为浏览器只信任服务端通过 Access-Control-Allow-Methods 响应头“白名单”式授权的动词。
看预检响应里的 Access-Control-Allow-Methods
这是最直接、最可靠的判断方式。当你的前端发起一个非简单请求（如带 Content-Type: application/json 的 PUT），浏览器会先发 OPTIONS 请求。你只需：
- 打开浏览器开发者工具 → Network 面板
- 触发目标请求（例如点击保存按钮）
- 找到对应路径的
OPTIONS请求 → 点开 → 查看 Response Headers - 确认是否存在
Access-Control-Allow-Methods: PUT, POST, DELETE这类字段，且其中包含你要用的动词
如果该 header 缺失、值为空、或没列出 PUT，那浏览器就会拦截后续真实请求，控制台报错类似 "Method PUT is not allowed by Access-Control-Allow-Methods"。
用 curl 手动发 OPTIONS 请求验证
绕过浏览器，直接检查服务端原始响应，能排除前端代码干扰，快速定位是配置问题还是调用问题：
- 运行：
curl -I -X OPTIONS https://api.example.com/users/123 - 观察输出中是否有
Access-Control-Allow-Methods: PUT, DELETE - 若返回 404 或 405，说明后端根本没注册 OPTIONS 路由；若返回 200 但无该 header，说明中间件或配置漏掉了方法声明
注意 credentials 和 Origin 的联动限制
如果你的请求带凭证（credentials: 'include'），除了 Access-Control-Allow-Methods，还需同时满足：
-
Access-Control-Allow-Origin必须是具体域名（如https://your-app.com），不能是* -
Access-Control-Allow-Credentials: true必须存在
三者缺一不可。哪怕 Methods 正确，但 Origin 或 Credentials 头不匹配，浏览器仍会拒绝响应。
避免误判：不是所有动词都需要预检
GET、POST（且 Content-Type 是 application/x-www-form-urlencoded、multipart/form-data 或 text/plain）、HEAD 属于简单请求，不触发 OPTIONS，也就不依赖 Access-Control-Allow-Methods。所以检测动词支持，只对非简单请求有意义——别拿 GET 去验证这个 header 是否存在。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
