CORS是浏览器基于同源策略实施的安全机制，通过预检请求（OPTIONS）与服务器协商跨域权限；解决方式包括后端配置Access-Control-Allow-*响应头、开发期使用代理，禁用浏览器安全策略仅限调试。

CORS（Cross-Origin Resource Sharing，跨域资源共享）是浏览器的一种安全机制，用来限制网页脚本向不同源（协议、域名、端口任一不同）的服务器发起请求。它不是 JavaScript 的 bug，也不是后端“不给访问”，而是浏览器主动拦截了不满足策略的响应，控制台会报类似 Access to fetch at 'https://api.example.com' from origin 'http://localhost:3000' has been blocked by CORS policy 的错误。

为什么会出现 CORS 错误？

核心原因是浏览器执行了同源策略（Same-Origin Policy），但又通过 CORS 机制提供了一种可控的“例外”方式。当前端发请求（尤其是带 credentials、非简单请求如 PUT/DELETE、自定义 header 等）时，浏览器会先发一个 预检请求（OPTIONS），询问服务器：“我这个跨域请求你允许吗？”——如果服务器没正确返回 Access-Control-Allow-* 相关响应头，浏览器就直接拒绝后续请求。

常见解决方式（按场景选）

✅ 后端配置响应头（推荐，治本）
让服务端在响应中添加以下关键头（以 Express 为例）：

• Access-Control-Allow-Origin: http://localhost:3000（或 *，但带 credentials 时不能用 *）
• Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
• Access-Control-Allow-Headers: Content-Type, Authorization
• Access-Control-Allow-Credentials: true（如需携带 cookie 或 auth token）
• 对 OPTIONS 预检请求，直接返回 204 状态码，不走业务逻辑

✅ 开发阶段：用代理（前端友好，绕过浏览器限制）
比如 Vue CLI 或 Vite 的 vite.config.js 中配置代理：

• Vite 示例：server.proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } }
• 请求写成 fetch('/api/users')，开发服务器自动转发到后端，因同源（都走 localhost:3000）就不触发 CORS

⚠️ 不推荐的方式（仅限调试，勿上线）
关闭浏览器安全策略（如 Chrome 启动时加 --disable-web-security）或装 CORS 插件——这些只影响本地浏览，无法解决用户真实访问时的问题，且存在安全风险。

注意几个易错点

• 前端设置了 credentials: 'include'，后端 Access-Control-Allow-Origin 就不能写 *，必须指定具体域名
• 预检失败常因后端没处理 OPTIONS 请求，或返回头拼写错误（比如写成 Access-Control-Allow-Originn）
• Nginx/Apache 等反向代理层也要透传或添加 CORS 头，否则即使后端写了，网关也可能覆盖掉
• fetch 和 axios 默认不带 cookie，要显式设置 credentials: 'include' 才会发送，后端也需配合 Allow-Credentials

基本上就这些。CORS 本质是浏览器和服务器之间的“协商协议”，关键在双方配合：前端明确需求（是否带凭证、什么方法），后端按需回应正确的头。不复杂但容易忽略细节。