Hi我是前端人类学跨域是浏览器同源策略导致的拦截行为——协议、域名、端口任一不同AJAX 请求即被阻断。解决方案没有万能药需根据场景权衡。本文将对比五种主流方案并给出选型建议。文章目录一、 现代标准答案CORS跨域资源共享1.1 核心原理1.2 两类请求1.3 关键配置含凭证二、后端代理模式Nginx 反向代理2.1 工作原理2.2 配置示例三、开发环境专用Webpack / Vite 代理四、古典方案与特殊场景JSONP 与 postMessage4.1 JSONP仅限 GET 的“取巧”方案4.2 postMessage页面间通信的桥梁五、总结如何选择一、 现代标准答案CORS跨域资源共享CORS 是 W3C 制定的现代跨域标准也是目前最推荐的生产环境解决方案。它由服务端主导通过在响应头中设置特定字段明确告诉浏览器“允许哪些源访问我的资源”。1.1 核心原理浏览器在发起跨域请求时会自动携带Origin头。服务端若允许需在响应头中携带Access-Control-Allow-Origin字段。1.2 两类请求CORS 将请求分为简单请求和非简单请求处理机制不同。简单请求如 GET/POSTContent-Type 为text/plain等浏览器直接发送请求服务器返回Access-Control-Allow-Origin即可。非简单请求如 PUT 方法或 Content-Type 为application/json浏览器会先发送一次OPTIONS 预检请求Preflight询问服务器是否允许。通过后才会发送真正的请求。1.3 关键配置含凭证如果请求需要携带 Cookie前后端都需要特殊设置前端xhr.withCredentials true原生 XHR或fetch(url, { credentials: include })。服务端Access-Control-Allow-Credentials: true。注意此时Access-Control-Allow-Origin不能设为*必须指定明确的域名。适用场景绝大多数前后端分离项目尤其是需要 POST、PUT、DELETE 等复杂请求时。优点支持所有 HTTP 方法安全性高功能完善。缺点需要后端配合配置。二、后端代理模式Nginx 反向代理如果无法或不想修改后端代码Nginx 反向代理是最稳健的生产环境方案。其核心思路是利用“服务端请求不受同源策略限制”这一特性让 Nginx 充当“中间人”。2.1 工作原理浏览器不再直接请求目标服务器而是请求同源的 Nginx 服务器。Nginx 将请求“转发”给目标服务器拿到响应后再返回给浏览器。从浏览器视角看请求和响应都在同一个源下自然不存在跨域问题。2.2 配置示例server { listen 80; server_name your-domain.com; # 前端静态资源 location / { root /usr/share/nginx/html; index index.html; } # 代理 API 请求 location /api/ { proxy_pass http://backend-server:8080/api/; # 转发到后端真实地址 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }适用场景生产环境特别是同一域名下需要代理多个后端服务时。优点对前端代码无侵入配置灵活可同时处理负载均衡、缓存等。缺点需要额外部署和维护 Nginx 服务器增加运维成本。三、开发环境专用Webpack / Vite 代理在本地开发时我们常通过webpack-dev-server或 Vite 的 proxy 功能解决跨域。它本质上是轻量级的本地反向代理原理与 Nginx 一致但仅限于开发环境。在vue.config.js或vite.config.js中配置// vite.config.jsexportdefault{server:{proxy:{/api:{target:http://backend-server:8080,// 后端地址changeOrigin:true,// 修改请求头中的 Originrewrite:(path)path.replace(/^\/api/,)}}}}适用场景本地开发调试。优点配置简单前端独立完成无需后端参与。缺点仅限开发环境代码部署到生产仍需其他方案。四、古典方案与特殊场景JSONP 与 postMessage4.1 JSONP仅限 GET 的“取巧”方案JSONP 利用script标签不受同源策略限制的特性通过src发送请求后端返回一个函数调用的 JavaScript 代码浏览器收到后立即执行从而拿到数据。缺点明显仅支持 GET 请求且存在 XSS 安全风险。如今除了一些老旧接口已不推荐使用。示例// 前端functionhandleData(data){console.log(data);}constscriptdocument.createElement(script);script.srchttp://api.example.com/data?callbackhandleData;document.body.appendChild(script);// 后端返回handleData({ name: test })4.2 postMessage页面间通信的桥梁postMessage是 HTML5 提供的 API专门用于不同窗口或 iframe 之间的安全跨域通信。适用场景页面嵌入了跨域的 iframe或需要与通过window.open打开的跨域窗口通信。优点功能强大双向通信安全性可控可校验origin。五、总结如何选择方案主导方适用场景优点缺点CORS服务端生产环境首选通用跨域请求标准、安全、支持所有请求类型需后端配置Nginx代理运维/后端生产环境不便修改后端代码时前端无感知配置灵活功能强大需部署维护NginxDev Proxy前端本地开发环境配置简单前端独立解决仅限开发环境JSONP前端/后端仅兼容老旧浏览器或只能GET的场景兼容性极好仅支持GET有安全隐患postMessage前端iframe / 新窗口 跨域通信专用于页面间通信安全可控不适用于AJAX请求在实际开发中最经典的组合是开发环境使用 Webpack/Vite 代理生产环境使用 CORS配合 Nginx 代理作为兜底。理解每一种方案的底层原理能帮助我们在遇到跨域报错时快速定位问题根源而不是盲目地复制粘贴配置代码。