CORS是前端面试必考题，也是junior开发者的头号卡点。面试官要看你懂这个策略为什么存在（安全）、什么时候触发预检（特定请求形态）、服务端怎么正确配置。
先讲同源策略：a.com上的脚本默认只能读a.com的响应。源 = 协议+域名+端口。目的是防止恶意站点通过脚本读你已登录的银行数据。
CORS是可控的例外：服务端通过Access-Control-Allow-Origin等头显式opt-in允许跨域读取。
简单请求：GET/HEAD或POST且Content-Type在安全集合里（x-www-form-urlencoded、multipart/form-data、text/plain），没有自定义头。浏览器直接发请求带Origin头，服务端用Access-Control-Allow-Origin响应。不匹配的话浏览器阻止JS读响应——但请求已经到了服务端。
预检请求：PUT/DELETE/PATCH，或Content-Type是application/json，或带Authorization等自定义头，都会触发OPTIONS预检。预检带Access-Control-Request-Method和Access-Control-Request-Headers，服务端用Access-Control-Allow-Methods和Access-Control-Allow-Headers响应。通过后才发真正的请求。预检结果可按Access-Control-Max-Age缓存。
带凭证（cookie）：客户端fetch credentials: "include"，服务端必须返回Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能是*必须是具体源——这是最常见的坑。
CORS（跨域资源共享）是浏览器允许脚本发跨域请求的机制。基础的同源策略规定：脚本默认只能读取同源（协议+域名+端口三者相同）的响应。这是为了防止evil.com的脚本调fetch("https://bank.com/api/balance")读你已登录的银行账户。CORS通过服务端响应头opt-in放开这个限制。跨域请求分两种。简单请求：GET或HEAD或POST，且Content-Type在安全白名单（application/x-www-form-urlencoded、multipart/form-data、text/plain），且没有自定义头比如Authorization。浏览器直接发带Origin头的请求。服务端可以响应Access-Control-Allow-Origin: https://a.com（或*）。响应头匹配浏览器才允许JS读响应；不匹配就拦截——注意请求还是到了服务端，响应只是JS读不到。预检请求：其他情况都要预检。包括PUT、DELETE、PATCH；或Content-Type: application/json；或带Authorization等自定义头。浏览器先发OPTIONS，带Access-Control-Request-Method: PUT和Access-Control-Request-Headers: Authorization, Content-Type。服务端必须返回Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Allow-Origin全部匹配。通过后真请求才发。预检可以缓存Access-Control-Max-Age秒内的相同请求跳过预检。凭证（cookie、HTTP Basic auth、TLS客户端证书）默认不跨域发送。要带cookie：客户端fetch的credentials设成"include"（或XHR的withCredentials=true）+服务端响应Access-Control-Allow-Credentials: true + Access-Control-Allow-Origin必须是具体源（通配符*被拒绝）。这三个条件都满足才行，是生产最常见的CORS坑。最后：CORS是浏览器强制的，Node或后端服务发同样的跨域HTTP请求没有任何CORS限制，因为没有浏览器参与。
先讲CORS的安全动机再讲机制，面试加分。
简单请求 vs 预检请求的三个判定条件要记牢。
"带cookie时Access-Control-Allow-Origin不能是*"是面试金句，立即显示实战经验。
临场忘了响应头名字，即答侠可以实时提示Access-Control-Allow-Origin/Methods/Headers。
不能，两者目的不同。CORS控制脚本能读什么，CSRF是通过受害者浏览器发出非预期操作。CSRF要靠token或SameSite cookie。
浏览器发OPTIONS、服务端响应、浏览器根据响应决定真请求发不发。状态变更类操作必须服务端也做CSRF防护，不能只靠CORS。
反向代理通过自己的域名转发，让请求变成同源，不需要CORS。CORS是浏览器层的协作。反向代理对前端更简单，CORS适合API确实在不同域的场景。