17370845950

同源策略限制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，前端还有办法吗

纯前端无法绕过同源策略。所谓“前端解决跨域”基本是误解。常见误区包括：

• 改 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/'（结尾多斜杠），导致匹配失败

CORS 的核心永远在服务端响应头，前端所有“技巧”要么是规避跨域场景，要么是配合服务端正确发起请求。最容易被忽略的是预检失败——它不报 CORS 错，而是在 Network 面板里看到一个 OPTIONS 请求状态为 404 或 500，此时前端 fetch 甚至不会触发 then 或 catch。