HTML无法解决CORS，因浏览器只检查HTTP响应头而非HTML中的meta或script；真正生效的是服务器返回的Access-Control-Allow-Origin等响应头。
HTML 本身不支持也不处理 CORS —— 它只是静态标记语言，跨域逻辑完全由浏览器对 fetch、XMLHttpRequest 等 API 的运行时行为控制，而响应头（如 Access-Control-Allow-Origin）必须由服务器返回。
为什么在 HTML 页面里加 meta 标签或 script 无法解决 CORS
常见误解是以为在 <head> 里加 <meta http-equiv="Access-Control-Allow-Origin" content="*"> 就能绕过限制。这完全无效：浏览器只检查 HTTP 响应头，不解析 HTML 中的 meta。script 标签加载外部 JS 或 JSONP 是另一套机制，和 CORS 无关，且只支持 GET。
真正起作用的只有服务器返回的响应头。哪怕你用 fetch('/api/data') 发请求，只要响应里没带合法的 Access-Control-Allow-Origin，浏览器就直接拦掉，控制台报 No 'Access-Control-Allow-Origin' header，连主请求都发不出去。
简单请求 vs 非简单请求：什么时候会触发 OPTIONS 预检
浏览器是否发预检请求，取决于你的请求是否满足“简单请求”条件：
立即学习“前端免费学习笔记（深入）”；
- 方法只能是
GET、HEAD或POST - 不能设置自定义请求头（比如
X-Auth-Token、X-Request-ID） -
Content-Type只能是text/plain、application/x-www-form-urlencoded或multipart/form-data
只要有一条不满足，浏览器就会先发一个 OPTIONS 请求。如果后端没正确响应这个预检（比如返回 404、405 或缺头），后续的 GET/POST 根本不会发出。
典型踩坑场景：fetch('/api/login', { method: 'POST', headers: { 'Content-Type': 'application/json' } }) —— 看似只是改个 Content-Type，实际已触发预检，后端若没配 Access-Control-Allow-Headers: Content-Type，就失败。
带 credentials 时 Access-Control-Allow-Origin 不能用通配符
前端如果写了 credentials: 'include'（比如要传 cookie 或 auth token），后端的 Access-Control-Allow-Origin 就不能设成 *，否则浏览器直接拒绝响应。
必须写明确域名：
- 开发环境可设为
http://localhost:3000 - 生产环境得是真实域名，如
https://app.example.com - 多个域名需显式列出，不能用正则或模糊匹配
同时，后端还得返回 Access-Control-Allow-Credentials: true，且该头不能和 Access-Control-Allow-Origin: * 共存 —— 浏览器会直接忽略整个响应。
暴露自定义响应头必须靠 Access-Control-Expose-Headers
即使后端正确返回了 X-Request-ID 或 X-RateLimit-Remaining 这类头，前端 JS 默认也读不到。因为浏览器只允许脚本访问一组“安全列表”内的响应头（如 Cache-Control、Content-Language 等）。
要让前端能读，后端必须额外加一个头：
Access-Control-Expose-Headers: X-Request-ID, X-RateLimit-Remaining
注意：Access-Control-Expose-Headers 不影响请求发送，只控制响应头是否对 JS 可见；漏配这个头，response.headers.get('X-Request-ID') 永远返回 null。
最常被忽略的是预检请求的处理 —— 很多人只配了主接口的 CORS 头，却忘了 OPTIONS 路径本身也要能返回正确响应头，尤其在用了 Spring Security、Nginx 或自定义路由前缀时，OPTIONS /api/user 可能根本没走到业务逻辑，而是被拦截或 405 了。
