浏览器地址栏里敲下回车的跨域那一刻，如果页面里的问题 JavaScript 想向另一个域名发请求，十有八九会被拦下来。前端控制台那行红字——Access to fetch at '...' from origin '...' has been blocked by CORS policy——几乎每个前端都见过。解决决这时候团队里通常会出现两种声音：前端说后端加个头就行，还后后端说这是端解浏览器的事你们前端自己代理一下。到底该谁解决？跨域

先把跨域这件事说清楚。它本质上是问题浏览器的一种安全机制，叫同源策略。前端协议、解决决域名、还后端口三者完全一致才算同源，端解否则浏览器就会限制脚本读取响应内容。跨域注意，问题请求其实发出去了，前端服务器也处理了，只是浏览器不让 JS 拿到结果。所以跨域不是网络故障，是浏览器的“门禁”。

那门禁的钥匙在谁手里？分情况。

最常见的场景是前后端分离项目，前端跑在 localhost:3000，后端 API 在 api.example.com。这时候最干净的做法是后端在响应头里加上 Access-Control-Allow-Origin。这活儿前端干不了，因为响应头是服务器发的。后端加一行配置，前端什么都不用改。我见过不少团队为这事扯皮，其实后端用 Nginx 加个 add_header，或者框架里挂个 CORS 中间件，五分钟的事。让前端去折腾 webpack 代理，开发环境能跑，上线又得改 Nginx，纯属绕远路。

但有些情况后端确实不方便动。比如调第三方接口，人家不可能为你改响应头。或者后端是遗留系统，改一行代码要走两周流程。这时候前端就得上手段了。开发阶段用 devServer 的 proxy，把请求转发到目标服务器，浏览器以为自己在访问同源地址。生产环境要么让运维在 Nginx 层做反向代理，要么用 Node 中间层转发。这些方案的本质都是“骗过浏览器”，让请求看起来是同源的。

还有一种容易被忽略的情况：带 Cookie 的跨域请求。这时候后端不能简单写 Access-Control-Allow-Origin: *，必须指定具体域名，还得加上 Access-Control-Allow-Credentials: true。前端 fetch 也要设 credentials: 'include'。两边少一个都白搭。这种场景下，单靠前端代理解决不了，因为 Cookie 的域和路径是后端和运维控制的。

我的判断是：跨域问题优先后端解决，前端方案是补充手段。理由很简单——跨域是 HTTP 协议层面的约束，后端作为响应方，天然拥有最直接的解决能力。前端代理本质上是在架构里加了一层，增加了部署复杂度和排查问题的难度。我见过一个项目，前端用 proxy 绕过了跨域，结果上线后 Nginx 配置没同步，接口 404 查了一整天。如果后端直接开 CORS，根本没这回事。

当然，现实里没有非黑即白的答案。小团队后端资源紧张，前端自己配个代理快速跑通，可以理解。大公司安全规范严，CORS 白名单要审批，前端用 BFF 层转发也常见。关键不是争论“该谁管”，而是团队内部要有个共识：谁改成本低、谁改风险小，就谁上。最怕的是前端觉得后端的事，后端觉得前端的事，最后用户看到的是白屏。

下次再遇到跨域，别急着搜“前端如何解决跨域”。先看看响应头里有没有 Access-Control-Allow-Origin。没有的话，把这条控制台报错截图发给后端，比什么都管用。