JavaScript无法单方面解决跨域问题，需服务端配合或改用不触发CORS的方案；fetch/XHR跨域时浏览器发OPTIONS预检，服务端未返回合法CORS响应头即报错；常见需配置的响应头包括Access-Control-Allow-Origin、Methods、Headers及Credentials（若带cookie）；script/img等标签加载、开发代理、SSR等场景不触发CORS。
JavaScript 本身无法绕过浏览器的同源策略，所谓“处理跨域问题”，本质是协调服务端配合、或换用不触发 CORS 的方案——不是前端代码能单方面解决的。
为什么 fetch / XMLHttpRequest 会报 CORS error
浏览器在发起跨域请求（协议、域名、端口任一不同）时，会先发一个 OPTIONS 预检请求。如果服务端没返回合法的 Access-Control-Allow-Origin 等响应头，就直接拦截，控制台抛出 CORS error。
- 常见错误现象：
Blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present - 注意：这个错误只在浏览器环境出现；
curl或后端调用完全不受影响 - 即使服务端加了
Access-Control-Allow-Origin: *，若前端带了credentials: true（比如传 cookie），就必须指定具体域名，不能用* -
Content-Type是application/json一般会触发预检；text/plain、application/x-www-form-urlencoded、multipart/form-data在满足简单请求条件时可跳过
服务端必须加的响应头有哪些
前端改不了 CORS 错误，真正要动的是服务端响应头。最小必要集通常包括：
-
Access-Control-Allow-Origin：必须，值为请求来源域名（如https://example.com）或*（无 credentials 时） -
Access-Control-Allow-Methods：列出允许的 HTTP 方法，如GET, POST, PUT, DELETE -
Access-Control-Allow-Headers：前端实际发送的自定义头（如Authorization、X-Request-ID）必须在此声明 - 若前端设了
credentials: true，还需加Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能为*
示例（Node.js + Express）：
立即学习“Java免费学习笔记（深入）”；
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', 'https://your-app.com');
res.header('Access-Control-Allow-Credentials', 'true');
res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
next();
});
哪些情况根本不用管 CORS
有些请求天然不触发同源策略检查，适合临时调试或特定场景：
-
<script>标签加载 JS：支持跨域，但只能 GET，且无法读响应体（JSONP 原理） -
<img>、<link>、<iframe>：可跨域加载资源，但受限于用途（比如 iframe 内容受同源限制） - 开发时用 Webpack/Vite 的
proxy配置：请求发给本地 dev server，它再转发到目标 API，对浏览器来说仍是同源 - 后端渲染或 SSR 场景：请求由服务端发出，不经过浏览器，CORS 不生效
代理和 JSONP 现在还值得用吗
JSONP 已基本淘汰：只支持 GET、无错误捕获、依赖全局函数、无法设置 header，现代项目应避免。开发代理（如 Vite 的 server.proxy）仍很实用，但它只是开发期手段，上线必须靠服务端配 CORS 或 BFF（Backend For Frontend）层。
真正容易被忽略的是：CORS 头必须由目标接口的服务端返回，而不是你自己的 Nginx 或 CDN 中间层——如果中间层覆盖或漏传了这些头，照样报错。
