JavaScript怎样处理跨域问题【教程】

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-Typeapplication/json 一般会触发预检;text/plainapplication/x-www-form-urlencodedmultipart/form-data 在满足简单请求条件时可跳过

服务端必须加的响应头有哪些

前端改不了 CORS 错误,真正要动的是服务端响应头。最小必要集通常包括:

  • Access-Control-Allow-Origin

    :必须,值为请求来源域名(如 https://example.com)或 *(无 credentials 时)
  • Access-Control-Allow-Methods:列出允许的 HTTP 方法,如 GET, POST, PUT, DELETE
  • Access-Control-Allow-Headers:前端实际发送的自定义头(如 AuthorizationX-Request-ID)必须在此声明
  • 若前端设了 credentials: true,还需加 Access-Control-Allow-Credentials: true,且 Access-Control-Allow-Origin 不能为 *

示例(Node.js + Express):

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

有些请求天然不触发同源策略检查,适合临时调试或特定场景:

  • 标签加载 JS:支持跨域,但只能 GET,且无法读响应体(JSONP 原理)
  • :可跨域加载资源,但受限于用途(比如 iframe 内容受同源限制)
  • 开发时用 Webpack/Vite 的 proxy 配置:请求发给本地 dev server,它再转发到目标 API,对浏览器来说仍是同源
  • 后端渲染或 SSR 场景:请求由服务端发出,不经过浏览器,CORS 不生效

代理和 JSONP 现在还值得用吗

JSONP 已基本淘汰:只支持 GET、无错误捕获、依赖全局函数、无法设置 header,现代项目应避免。开发代理(如 Vite 的 server.proxy)仍很实用,但它只是开发期手段,上线必须靠服务端配 CORS 或 BFF(Backend For Frontend)层。

真正容易被忽略的是:CORS 头必须由目标接口的服务端返回,而不是你自己的 Nginx 或 CDN 中间层——如果中间层覆盖或漏传了这些头,照样报错。