跨域请求是浏览器因同源策略限制而无法读取不同源响应内容的安全机制；cors是标准解决方案，需后端配置响应头，开发期可用代理绕过。
跨域请求是指浏览器从一个源（协议 + 域名 + 端口）向另一个不同源发起的 HTTP 请求。由于同源策略（Same-Origin Policy）限制，JavaScript 默认无法读取跨域响应内容，这是浏览器的安全机制，不是 JavaScript 或后端的问题。
为什么会出现跨域问题
同源策略只限制前端脚本（如 fetch、XMLHttpRequest、WebSocket 连接中的响应读取等），不阻止请求发出。比如：
• 页面在 https://a.com，请求 https://b.com/api/user → 跨域
• 页面在 http://localhost:3000，请求 http://localhost:8000/data → 跨域（端口不同）
• 页面在 https://example.com，请求 http://example.com/api → 跨域（协议不同）
CORS 是最常用且标准的解决方式
服务端通过设置响应头，明确允许哪些源访问资源。前端无需额外代码，但需确保后端配置正确：
-
Access-Control-Allow-Origin：指定允许的源，如
*（不支持带凭证的请求）或https://a.com -
Access-Control-Allow-Credentials：设为
true时，前端必须在请求中加credentials: 'include' - Access-Control-Allow-Methods 和 Access-Control-Allow-Headers：声明允许的请求方法和自定义头
注意：预检请求（OPTIONS）由浏览器自动触发，适用于 PUT/DELETE、带自定义 header 或 credentials 的请求，后端需正确响应它。
立即学习“Java免费学习笔记（深入）”；
前端开发阶段的临时方案
本地调试时可绕过限制，但不能用于生产：
- 启动浏览器时添加
--disable-web-security --user-data-dir=/tmp（仅测试，有安全风险） - 使用 webpack-dev-server 的
proxy配置，把 API 请求代理到目标服务器（如请求/api→ 转发到https://b.com） - Vite 项目用
server.proxy，同样原理
其他可行但适用场景有限的方法
• JSONP：仅支持 GET，依赖服务端返回可执行的 JS 函数调用，已基本淘汰
• PostMessage：用于 iframe 通信，非 HTTP 请求，适合嵌入第三方页面交互
• 服务端代理：前端请求自己的后端，再由后端转发并返回结果（本质是“非跨域”）
基本上就这些。核心还是理解同源策略的目的，优先推动后端配好 CORS，开发期用代理，避免在前端硬扛跨域。
