CORS（跨源资源共享）

同源策略与 CORS 的由来

浏览器的同源策略规定：页面脚本只能读取与自身同源（协议+域名+端口完全一致）的响应。这防止了恶意网站读取用户在银行的数据——即便 Cookie 随请求发出，恶意脚本也读不到响应内容。

但现实中，前端（app.example.com）调后端 API（api.example.com）是不同源，合法需求也被拦截。CORS（RFC 6454 同源定义，W3C CORS 规范 2014 年）给出解法：服务器在响应头加 Access-Control-Allow-Origin: https://app.example.com，浏览器看到后才放行 JavaScript 读取响应。关键要理解：CORS 是浏览器的行为，服务器实际上已经收到并处理了请求，只是浏览器拦截了响应；用 curl 直接请求则完全不受 CORS 约束。[1]

预检请求（Preflight）

对于非简单请求（非 GET/POST、带自定义头、Content-Type 不是表单类型），浏览器在正式请求前会先发一个 OPTIONS 请求询问服务器是否允许——这就是预检（Preflight）。服务器用 Access-Control-Allow-Methods、Access-Control-Allow-Headers 等头回答。

配置 Access-Control-Allow-Origin: * 意味着允许任何来源，但这与 Access-Control-Allow-Credentials: true（携带 Cookie）不能同时使用——允许任意来源携带凭据是严重的安全漏洞。很多开发者为了「解决 CORS」直接粗暴地设置 *，却没意识到这在某些场景等于开了后门。正确做法是维护白名单，动态匹配请求来源。