跨域请求是什么？JavaScript怎么处理？

跨域请求是浏览器基于同源策略实施的安全限制，阻止网页脚本向不同协议、域名或端口的服务器发起HTTP请求，并非JavaScript缺陷，而是保护用户数据的关键防线；本文深入解析其原理，并对比CORS（推荐首选，需服务端配合配置响应头）、代理服务器（开发阶段便捷方案）和已淘汰的JSONP，强调真正有效的解决方案在于前后端协同——优先推动服务端正确启用CORS，既安全规范又利于长期维护。

跨域请求是指浏览器中当前网页的脚本尝试向不同源（协议、域名、端口任一不同）的服务器发起 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、无错误捕获、安全性低，现代项目不推荐使用。