跨域请求是什么？JavaScript如何解决？

跨域请求是浏览器出于安全考虑，依据同源策略默认拦截不同源（协议、域名或端口任一不同）的前端脚本请求，并非JavaScript缺陷，而是防止数据窃取的关键防线；主流解决方案包括服务端配置CORS（推荐首选，标准且可控）、开发阶段使用代理服务器（如Vite/Webpack代理，让请求“看似同源”），以及早已过时、仅支持GET的JSONP；理解本质——JS无法单方面突破限制，必须通过服务端协作或构建层中转——才能高效、安全地打通前后端通信。

跨域请求是指浏览器中当前网页的脚本尝试向不同源（协议、域名、端口任一不同）的服务器发起 HTTP 请求，由于同源策略（Same-Origin Policy）限制，这类请求默认被阻止。这不是 JavaScript 的“bug”，而是浏览器的安全机制，防止恶意网站读取其他站点的敏感数据。

为什么会出现跨域问题

同源策略是浏览器的核心安全模型，它要求脚本只能读写同源的资源。例如：

• http://a.com 页面中的 JS 尝试请求 http://b.com/api/user → 跨域，被拦截
• https://a.com 请求 http://a.com → 协议不同，也跨域
• http://a.com:8080 请求 http://a.com:3000 → 端口不同，同样跨域

注意：跨域限制只存在于浏览器端；用 curl、Postman 或后端代码发请求不受影响。

CORS（跨域资源共享）——最常用的标准方案

服务端主动声明允许哪些源访问资源，浏览器根据响应头决定是否放行。关键响应头包括：

• Access-Control-Allow-Origin：指定允许的源，如 "https://a.com" 或通配符 "*"（但带凭据时不能用 *）
• Access-Control-Allow-Credentials：设为 true 才允许携带 Cookie、Authorization 等凭证
• Access-Control-Allow-Methods：列出允许的 HTTP 方法，如 "GET, POST, PUT"
• Access-Control-Allow-Headers：声明允许的自定义请求头

前端只需正常发请求（如 fetch 或 axios），无需额外配置；真正起作用的是服务端返回的这些头。

JSONP（仅限 GET，已基本淘汰）

利用

服务端响应：handleData({"name": "Alice"})。缺点明显：只支持 GET、无错误捕获、安全性低，现代项目不推荐使用。