浏览器报错“CORS跨域”？别慌，这是后端在跟你谈判

前端开发日常里，最扎眼的莫过于控制台那行红字：Blocked by CORS policy。很多新人第一反应是代码写错了，或是网络抽风。其实这只是浏览器的同源策略在“拉警戒线”。它并不针对你，只是默默挡住了来自不同协议、域名或端口的请求。理解CORS（跨域资源共享），不是背几个响应头，而是摸清浏览器与服务器之间的谈判规则。

跨域的底层逻辑很直白。当你用 fetch 或 axios 发起请求时，浏览器会先判断请求属性。若不满足简单条件，它会先派出一辆侦察车——发送 OPTIONS 预检请求。服务器得明确点头，写明允许哪些来源、哪些HTTP方法、甚至允许携带哪些自定义头。浏览器拿到许可清单，才会放下戒备，发出真正的业务请求。只要中间环节有任何错位，请求就会被直接掐断。

很多人纳闷，明明之前正常的 POST 请求，为什么改了 Header 就开始报跨域？application/json 格式直接触发了预检机制。目前只有 text/plain、multipart/form-data 和 application/x-www-form-urlencoded 这三种属于浏览器的“免检通道”。一旦越界，服务端必须在响应头里把路铺平。

本地开发阶段，与其对着文档反复试错，不如直接用构建工具的代理转发。在 Vite 或 Webpack 配置中加上 proxy 规则，将 /api 开头的路径全部指向目标服务地址。浏览器眼里全是同源通信，彻底绕过CORS校验，联调效率直线上升。等项目交付上线，再切回生产环境的正规路线。

线上环境没法绕道，全靠服务端头字段兜底。最核心的配置是 Access-Control-Allow-Origin，涉及用户登录态或敏感数据时，千万别图省事写成 *。需要动态读取请求方的 Origin 返回，并配套开启 Access-Control-Allow-Credentials: true 才能顺利携带 Cookie。若是复杂请求，还得补全 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers。预检状态码回到 204 或 200，才算握手完毕。

这里藏着一个常被忽略的真相：CORS 仅在浏览器渲染环境中生效。Node.js 脚本或 Python 爬虫发起同类调用，终端只会打印数据，绝不会弹出拦截警告。跨域本质是浏览器的单向自我保护，而非网络层的硬性封堵。调试时若确认服务端已返回完整头信息，浏览器却依然报错，大概率是预检缓存作祟。清除一下缓存或更换测试用的临时 Origin，卡点往往迎刃而解。

跨域从来不是阻碍开发的绊脚石，而是一套清晰的安全契约。把接口调用当成一次双向确认，前端把控参数格式，后端开放权限边界。理顺了头字段的对应关系，那些刺眼的红色提示自然会褪去。下次再碰上CORS拦截，不妨先排查预检是否被触发，或者凭证开关是否冲突。摸清它的运作脾气，前后端协作的链路自然就通了。