CORS（跨源资源共享）是一套基于HTTP头部的机制，它允许运行在一个源（域名）上的Web应用，获得访问来自不同源的服务器上的特定资源的权限。下面这个表格能帮你快速抓住其核心要点。
| 特性 | 简单请求 | 预检请求 (非简单请求) |
|---|---|---|
| 触发条件 | 方法是GET、POST、HEAD，且内容类型为特定值 | 使用PUT、DELETE等方法，或包含自定义头部 |
| 通信流程 | 1. 浏览器直接发送实际请求 2. 服务器响应中需包含CORS头部 | 1. 浏览器先发OPTIONS请求（预检） 2. 服务器响应预检请求 3. 预检通过后，浏览器发送实际请求 |
| 关键头部 | 请求头: Origin 响应头: Access-Control-Allow-Origin |
预检请求头: Origin, Access-Control-Request-Method, Access-Control-Request-Headers 预检响应头: Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers |
🌐 理解CORS的背景：同源策略
浏览器出于安全考虑，实施了同源策略。它默认阻止一个域下的网页的JavaScript脚本，与另一个不同源的服务器进行数据交互。
判断是否同源，需要比较协议、域名、端口 这三者是否完全一致。例如，从 https://www.example.com:443访问 https://api.example.com会因为域名不同（wwwvs api）而被视为跨域并被浏览器阻止。CORS机制就是为了在保证安全的前提下，合法地打破这个限制。
⚙️ CORS的工作原理与关键HTTP头部
CORS通过一系列新增的HTTP头部字段，让服务器能够声明哪些源有权访问其资源，以及允许使用哪些HTTP方法或自定义头。
-
Origin：由浏览器自动添加到跨域请求中，表明请求的来源。 -
Access-Control-Allow-Origin：这是服务器返回的最重要的响应头。它的值可以是一个具体的源（如https://www.example.com），表示只允许该源访问；也可以是通配符*，表示允许任何源访问。 -
Access-Control-Allow-Methods：指明实际请求所允许使用的HTTP方法（如GET, POST, PUT）。 -
Access-Control-Allow-Headers：指明实际请求中允许携带的首部字段。 -
Access-Control-Allow-Credentials：当其值为true时，表示服务器允许请求携带凭证信息，如Cookies或HTTP认证信息。当需要携带凭证时，Access-Control-Allow-Origin不能设为通配符*，必须指定明确的源。 -
Access-Control-Max-Age：指定预检请求的结果可以被缓存多久（秒），以减少不必要的预检请求，提升性能。
🔧 如何配置CORS
配置CORS主要在服务器端完成。以下是一些常见后端框架的配置思路：
-
Node.js (Express) ：可以使用
cors中间件。 -
Spring Boot (Java) ：可以通过配置
WebMvcConfigurer来定义全局CORS规则。 -
Nginx ：作为反向代理时，可以在配置文件中添加
add_header指令来设置CORS响应头。
⚠️ 常见问题与安全实践
-
预检请求失败 ：确保服务器正确响应
OPTIONS请求，并返回了正确的CORS头部，特别是Access-Control-Allow-Methods和Access-Control-Allow-Headers要涵盖实际请求所使用的值。 -
凭证未被发送 ：检查前端是否设置了
withCredentials: true（如使用Fetch API，需设置credentials: 'include'），同时服务器响应必须包含Access-Control-Allow-Credentials: true，并且Access-Control-Allow-Origin不能为*。 -
安全最佳实践 ：在生产环境中，尽量避免使用
Access-Control-Allow-Origin: *，特别是当你的接口涉及敏感数据或用户凭证时。最好配置一个允许的源白名单。同时，只开放必要的HTTP方法和请求头，最小化权限范围。
希望这些解释能帮助你清晰地理解CORS。如果你对某个具体的配置场景或遇到的错误有进一步疑问，我很乐意提供更详细的探讨。