跨域问题本质是浏览器同源策略限制，防止恶意网站窃取用户数据；JSONP利用script标签绕过但仅支持GET且存XSS风险；CORS通过服务端响应头正向解决，需配置Access-Control-Allow-Origin等字段。
跨域问题本质是浏览器的同源策略限制，不是JavaScript语言本身的问题，而是浏览器出于安全考虑，阻止前端脚本向非同源（协议、域名、端口任一不同）的服务器发起HTTP请求并读取响应。
为什么会有跨域限制？
同源策略防止恶意网站通过脚本窃取其他站点的用户数据（比如 Cookie、DOM 内容、API 响应）。例如：你登录了网银页面，另一个恶意网页若能随意发请求到网银接口并读取返回结果，就可能泄露账户信息。
注意：跨域限制只影响浏览器中的 JavaScript 发起的请求（如 fetch、XMLHttpRequest），不影响 HTML 标签加载资源（如 、<script></script>、），这也是 JSONP 能绕过限制的基础。
JSONP 是怎么“绕过”跨域的？
JSONP（JSON with Padding）利用 <script></script> 标签不受同源策略限制的特性。它把请求封装成一个 script 标签的 src 请求，并要求后端返回一段可执行的 JavaScript 函数调用，参数是真正的数据。
立即学习“Java免费学习笔记（深入）”；
典型流程：
- 前端定义一个全局回调函数，比如 window.handleData = function(data) { ... }
- 动态创建 <script src="https://api.example.com/data?callback=handleData"></script>
- 服务端返回：handleData({"name": "Alice", "age": 30})
- 浏览器执行该脚本，触发回调，拿到数据
缺点明显：只支持 GET 请求；依赖服务端配合返回特定格式；没有错误捕获机制（script 加载失败无法区分是网络问题还是语法错误）；存在 XSS 风险（执行任意返回的 JS）；已基本被现代项目淘汰。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
CORS 是如何正向解决跨域的？
CORS（Cross-Origin Resource Sharing）是 W3C 标准，由浏览器和服务端协作完成。核心是服务端在 HTTP 响应头中声明允许哪些源访问资源，浏览器据此决定是否放行响应。
关键响应头示例：
- Access-Control-Allow-Origin: https://your-app.com（或 *，但带凭证时不能用 *）
- Access-Control-Allow-Methods: GET, POST, PUT
- Access-Control-Allow-Headers: Content-Type, Authorization
- Access-Control-Allow-Credentials: true（允许携带 Cookie 或认证信息）
- Access-Control-Expose-Headers: X-RateLimit-Limit（指定前端 JS 可读的响应头）
简单请求（如 GET/POST + 纯文本 Content-Type）直接发送；预检请求（如 PUT、带自定义 Header 的请求）会先发一个 OPTIONS 请求，确认服务端允许后再发真实请求。
前端无需额外编码，只需正常使用 fetch 或 axios；重点在于后端正确配置响应头。开发中常见问题：本地启动的 http://localhost:3000 访问后端 API 时，服务端忘了加 Access-Control-Allow-Origin，导致请求被浏览器拦截。
其他补充方案
开发阶段常用代理（如 Webpack DevServer 的 proxy、Vite 的 server.proxy）把 /api 请求转发到后端，让浏览器认为是同源；生产环境推荐 Nginx 反向代理统一域名，彻底规避跨域问题。
不复杂但容易忽略：跨域是浏览器行为，Node.js、Python 等后端发起的请求不受限；前后端分离项目中，务必确认 API 接口是否已开启 CORS，而不是在前端反复改代码。
