一、先看症状：那片熟悉的红色报错

只要你做过前后端分离开发。一定见过它：

Access to XMLHttpRequest at 'http://api.example.com' from origin 'http://localhost:' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on requested resource.

说到后端说，“我接口明明返回了数据也查出来了你前端是不是写错了？”

前端说这方面。“Network 里明明能看到响应，可 JS 就是拿不到数据！”

问题不在后端，也不完全在前端——问题出在浏览器这个“中间人”身上。响应其实已经回来了但浏览器看了一眼响应头，发现“没有通行证”。于是把数据扣押了不让 JS 读取。

这就是跨域。其实，

二、什么是“域”？

要理解跨域，先得知道什么叫“同源”。

域 = 协议 + 域名 + 端口。三者必须完全一致，才叫同源。老实说，只要有一个不一样，就是跨域。

使用者痛点聚焦：为什么我在本地跑起来却总是报跨域？

• P1： 接口地址写对了却仍然提示 “No ‘Access-Control-Allow-Origin’ header”；
• P2： 本地调试能正常请求，部署到生产环境后又被拦住；
• P3： 带 Cookie 的跨域请求总是返回 403 或空数据。These symptoms stem from an incomplete understanding of **origin**。**same‑origin policy**,and **CORS** headers.

  三、浏览器为什么要拦你？

  虽然第一次遇到跨域时会忍不住抱怨浏览器“有病”，但这其实是它在为你保驾护航——防止恶意脚本窃取敏感信息。同源策略**规定脚本只能读取**与页面同源的资源。 如果没有这层限制。攻击者可以轻易发起 CSRF攻击：

  1. 使用者登录银行网站 bank.com，Cookie 中保存登录态；
  2. 随后打开恶意站点 evil.com；怎么说呢，
  3. evil.com 页面里的 JS 向 bank.com/api/transfer 发起请求；
  4. 浏览器自动携带 bank.com 的 Cookie；
  5. 服务器误以为是合法请求，完成转账。
  同源策略只阻止**脚本读取响应**。并不阻止请求本身发出去，这也是为什么你能在 Network 面板看到请求却拿不到数据。

  . 假设没有同源限制会怎样？，不过，

  CORS = Cross‑Origin Resource Sharing。是 W3C 标准，用来让服务器显式授权哪些跨域请求可以被浏览器放行。

  CORS 并不是让你绕过安全机制，而是让服务器主动声明："我允许来自 http://localhost:3000 的访问"