同源策略限制JavaScript读取跨域响应内容，而非禁止跨域请求；同源指协议、域名、端口三者完全一致；fetch与XMLHttpRequest跨域行为一致，均依赖CORS响应头。
同源策略到底限制了什么
同源策略（Same-Origin Policy）不是禁止跨域请求，而是限制 JavaScript 脚本读取跨域响应内容。浏览器会正常发出请求（比如 fetch('https://api.other.com/data')），但只要响应头里没有合法的 Access-Control-Allow-Origin，脚本就拿不到 response.text()、response.json() 等数据，控制台报错：Blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present。
注意：同源指协议（http/https）、域名（example.com）、端口（:8080）三者完全一致。哪怕只是 http://a.com 请求 https://a.com，也算跨域。
fetch 与 XMLHttpRequest 的跨域行为一致吗
行为完全一致。两者都受同源策略约束，也都依赖服务端返回的 CORS 响应头。区别只在语法和默认行为：
-
fetch默认不带 cookie，需显式加{ credentials: 'include' }；XMLHttpRequest默认也不发 cookie，但部分老版本 IE 需设withCredentials = true -
fetch不会因 HTTP 状态码（如 404、500）自动 reject，需手动检查response.ok；XMLHttpRequest的onerror只在网络失败时触发，不涵盖 4xx/5xx - 预检请求（preflight）触发条件相同：非简单请求（如含
Content-Type: application/json、自定义 header、PUT/DELETE方法）都会先发OPTIONS
后端没配 CORS，前端还有办法吗
纯前端无法绕过同源策略。所谓“前端解决跨域”基本是误解。常见误区包括：
立即学习“Java免费学习笔记（深入）”；
- 改
localhost端口或加代理（开发时有效，本质是让请求不跨域，不是突破策略） - 用
JSONP：仅支持GET，依赖服务端包裹回调函数，现代项目已淘汰 - 把请求发到自己后端再中转：这是合法方案，但属于服务端代理，不是前端突破
真正可控的路径只有两个：
- 说服后端加上
Access-Control-Allow-Origin: *（公开 API）或指定域名（如Access-Control-Allow-Origin: https://myapp.com） - 如果后端是自己维护的，确保同时设置必要头：
Access-Control-Allow-Credentials: true（若需 cookie）、Access-Control-Allow-Headers（如含Authorization）、Access-Control-Allow-Methods
开发环境代理怎么配才不踩坑
以 Vite 为例，vite.config.ts 中的 server.proxy 是最常用方式。关键点不是写对路径，而是理解代理时机：
export default defineConfig({
server: {
proxy: {
'/api': {
target: 'https://backend.example.com',
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, '')
}
}
}
})
这个配置只在开发服务器（vite dev）运行时生效，构建后的生产代码仍直连原始域名。常见错误：
- 误以为代理能解决生产跨域 → 实际不能，生产必须靠后端配 CORS 或 CDN 透传头
- 没设
changeOrigin: true→ 后端收到的Origin还是http://localhost:5173，可能被拒绝 - 代理路径和前端请求路径不一致 → 比如前端调
fetch('/api/users')，但 proxy 写成'/api/'（结尾多斜杠），导致匹配失败
OPTIONS 请求状态为 404 或 500，此时前端 fetch 甚至不会触发 then 或 catch。 
