JavaScript跨域问题本质是浏览器同源策略限制：非同源请求的响应被拦截，需后端配置CORS响应头（如Access-Control-Allow-Origin）授权，前端无法真正“绕过”，只能代理或调试时禁用安全策略。
JavaScript 的跨域问题，本质是浏览器出于安全考虑实施的同源策略（Same-Origin Policy）限制：当网页中的脚本尝试向非同源（协议、域名、端口任一不同）的服务器发起请求（如 fetch 或 XMLHttpRequest）时，即使请求实际发出去了、服务器也正常响应了，浏览器也会拦截响应内容，不交给 JavaScript 处理，并在控制台报错（如 “No 'Access-Control-Allow-Origin' header is present”）。
为什么不是所有请求都报跨域错误？
有些请求看似“跨域”，但不会触发 CORS 检查，比如：
- 普通 HTML 标签加载资源（、、），它们不受同源策略限制（但无法读取响应体）；
- 表单 提交，能跨域发送，但无法用 JS 获取响应；
- 简单请求（GET/HEAD/POST 且 Content-Type 为 text/plain、application/x-www-form-urlencoded 或 multipart/form-data，且无自定义 header）会直接发送，但响应仍需服务端明确允许才能被 JS 读取；
- 非简单请求（如带 Authorization header、application/json 类型、或自定义 header）会先发一个 OPTIONS 预检请求，服务端必须正确响应预检，后续真实请求才被允许。
后端配置 CORS 响应头（最标准解法）
核心是让服务端在响应中带上正确的 HTTP 头：
-
Access-Control-Allow-Origin：指定允许访问的源，如https://example.com；设为*表示允许任意源（但此时不能带凭证）； -
Access-Control-Allow-Credentials：若前端请求设置了credentials: 'include'（如需传 cookie），此头必须为true，且Allow-Origin不能为*，必须写具体域名； -
Access-Control-Allow-Methods：列出允许的 HTTP 方法，如GET, POST, PUT, DELETE； -
Access-Control-Allow-Headers：列出允许的请求头，如Content-Type, Authorization； -
Access-Control-Expose-Headers（可选）：指定哪些响应头可以被 JS 读取（默认只暴露简单响应头）；
常见框架配置示例：
- Express（Node.js）：用 co 中间件，
rsapp.use(cors({ origin: 'https://your-app.com', credentials: true }))；
- Nginx：在 location 块中添加 add_header 'Access-Control-Allow-Origin' 'https://your-app.com'; 等；
- Spring Boot：加 @CrossOrigin(origins = "https://your-app.com", allowCredentials = "true") 注解。
前端绕过方案（仅限开发或特殊场景）
这些方法不解决根本问题，也不适用于生产环境：
-
开发时禁用浏览器安全策略：Chrome 启动时加
--disable-web-security --user-data-dir=/tmp（危险，仅临时调试）； -
使用代理（推荐开发阶段）：Webpack Dev Server、Vite、Vue CLI 等支持 proxy 配置，把
/api请求代理到后端地址，使前端请求看起来是同源的； -
JSONP（已淘汰）：仅支持 GET，依赖
标签，服务端需配合返回函数调用，安全性差，现代项目不应使用；
其他注意事项
常见踩坑点：
- 本地文件打开（
file://协议）下运行 HTML，所有请求都会被当作跨域，因为没有 origin； - 前后端域名看似一样，但一个是
www.example.com，一个是example.com，属于不同源； - HTTP 和 HTTPS 视为不同源；
- 端口不同（如
8080vs3000）也算跨域； - CORS 是浏览器行为，curl、Postman、服务端请求不受影响。
本质上，CORS 不是“阻止请求”，而是“控制响应是否可被 JS 使用”。只要服务端正确声明权限，浏览器就会放行。关键不在前端“突破”，而在后端“授权”。
