CORS策略由服务器响应头控制，前端JavaScript无法设置；服务端需通过Access-Control-Allow-Methods头明确允许的HTTP方法，并配合Access-Control-Allow-Origin等头生效。
CORS 策略本身不是 JavaScript 控制的，而是由服务器通过响应头决定的。JavaScript（如 fetch 或 XMLHttpRequest）发起跨域请求时，浏览器会自动检查服务器返回的 CORS 响应头，判断是否允许该请求继续执行。因此，“用 JavaScript 设置 CORS 允许指定方法”这个说法不准确——真正起作用的是服务端配置，前端只需按常规方式发请求即可。
服务端需明确声明允许的 HTTP 方法
要让特定方法（如 GET、POST、PUT、DELETE）能跨域访问资源，服务器必须在响应中设置 Access-Control-Allow-Methods 头，并列出被许可的方法。这个头通常和 Access-Control-Allow-Origin 一起使用。
-
只允许 GET 和 POST：响应头应包含
Access-Control-Allow-Methods: GET, POST -
允许所有常用方法：可设为
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS - 注意预检请求：当请求使用了非简单方法（如 PUT）或自定义 header，浏览器会先发一个 OPTIONS 预检请求。此时服务器必须对 OPTIONS 请求也返回合法的 CORS 头，否则实际请求不会发出
常见服务端配置示例
不同后端框架写法略有差异，但核心逻辑一致：
-
Node.js（原生）：在响应前手动设置
res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT') -
Express.js：可用
cors中间件并传入配置：cors({ methods: ['GET', 'POST', 'PUT'] }) -
ASP.NET Core：在策略中调用
policy.WithMethods("GET", "POST", "PUT")
前端代码无需额外处理
只要服务端正确设置了 Access-Control-Allow-Methods，前端就可以像同源一样使用标准 API：
立即学习“Java免费学习笔记（深入）”；
- 发送 PUT 请求：
fetch('/api/user/123', { method: 'PUT', body: JSON.stringify(data) }) - 发送 DELETE 请求：
fetch('/api/user/123', { method: 'DELETE' }) - 浏览器会在请求中自动带上
Origin头；若服务端响应中Access-Control-Allow-Methods包含该方法，且Access-Control-Allow-Origin匹配当前源，请求就成功
容易忽略的关键点
仅设置 Access-Control-Allow-Methods 不够，还需配套其他头才能让非简单请求生效：
- 必须有
Access-Control-Allow-Origin（不能为*时搭配凭据） - 若请求带自定义 header（如
Authorization），还要设置Access-Control-Allow-Headers - 若需携带 Cookie 或认证信息，必须同时设置
Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能是*
