jQuery处理二级域名跨域问题的核心上文归纳在于：针对同主域下的二级域名，最直接且兼容性最好的方案是利用 document.domain 属性进行同源模拟；而在现代Web开发中，更推荐通过后端配置 CORS（跨域资源共享）或使用 Nginx 反向代理来彻底解决跨域限制，以保障安全性与性能。
同源策略与二级域名的限制
在深入探讨解决方案之前，必须明确浏览器同源策略（Same-Origin Policy）的严格定义，浏览器默认只允许脚本访问与当前页面“同源”的资源，所谓的“同源”，要求协议、域名和端口完全一致，即便 www.example.com 和 api.example.com 共享同一个主域名，但在浏览器看来，它们属于不同的源，当使用 jQuery 的 $.ajax 试图从一个二级域名请求另一个二级域名的数据时，浏览器会拦截请求或抛出跨域错误，理解这一机制是解决 jQuery 二级域名交互的前提。
利用 document.domain 属性（经典方案）
对于需要通过 iframe 进行父子页面通信，或者在特定环境下进行 Ajax 调用的场景，设置 document.domain 是最传统的 jQuery 二级域名解决方案。
基本原理
document.domain 属性可读可写，通过将两个页面的 document.domain 设置为相同的值（通常是它们的主域名），浏览器会认为这两个页面属于同一个源，从而允许它们互相访问 DOM 或进行数据交互。
实施步骤与代码示例
假设父页面在 www.example.com，子页面在 app.example.com，且子页面中包含需要调用的 jQuery 接口。
在父页面（www.example.com）中：
// 必须在加载任何 iframe 之前设置 document.domain = 'example.com'; // 加载 iframe
在子页面（app.example.com）中：
// 同样设置为主域名 document.domain = 'example.com';
设置完成后，父页面中的 jQuery 代码即可通过 iframe 的 contentWindow 访问子页面的全局变量或函数，反之亦然，如果涉及 Ajax 请求，且目标接口在另一个二级域名下，设置 document.domain 后，部分浏览器环境下（如旧版 IE）可能允许请求，但在现代浏览器中，这主要解决了 DOM 访问限制，Ajax 仍需配合其他手段。
局限性分析
此方案有一个严格的限制：设置后的域名必须是当前域名的后缀。www.example.com 可以设为 example.com，但不能设为 baidu.com，此方案会轻微降低页面的安全性，因为一旦设置为主域，该主域下的所有其他恶意脚本如果也能注入,理论上可以访问当前页面。
CORS 跨域资源共享（现代标准方案）
随着 HTML5 的普及，CORS 已经成为解决 jQuery 二级域名乃至完全跨域请求的主流且专业的解决方案，它不需要前端修改 document.domain，而是通过 HTTP 头部来告知浏览器允许跨域。
服务端配置
要实现 jQuery 跨域请求，服务器端（如 api.example.com）必须返回响应头 Access-Control-Allow-Origin，如果希望允许 www.example.com 访问,配置如下：
Access-Control-Allow-Origin: http://www.example.com如果希望允许所有主域名下的二级域名访问（需谨慎）,可以设置为：
Access-Control-Allow-Origin: *jQuery 前端调用
在配置好服务端后，jQuery 的 $.ajax 代码无需特殊处理，只需正常编写即可，浏览器会自动发起“预检”请求（OPTIONS），确认服务器允许跨域后，再发送实际的 GET 或 POST 请求。
$.ajax({
url: 'http://api.example.com/getData',
type: 'GET',
dataType: 'json',
success: function(data) {
console.log('跨域数据获取成功', data);
},
error: function(xhr, status, error) {
console.error('请求失败', error);
}
});
优势
CORS 方案支持所有类型的 HTTP 请求（GET, POST, PUT, DELETE），且比 JSONP 更安全、更强大，它不破坏同源策略的安全性模型，是专业 Web 开发的首选。
Nginx 反向代理（架构级解决方案）
对于追求极致性能和完全屏蔽跨域细节的架构，使用 Nginx 作为反向代理将二级域名接口“伪装”为同域请求是最高效的手段。
实现逻辑
在 Nginx 配置中，将 www.example.com/api/ 的请求转发到后端的 api.example.com，对于前端 jQuery 它只是请求了当前域名下的 /api/ 接口,根本不存在跨域问题。
配置示例
server {
listen 80;
server_name www.example.com;
location /api/ {
proxy_pass http://api.example.com/;
# 保持 Host 头部，确保后端能正确识别
proxy_set_header Host $host;
}
}
专业见解
这种方案将跨域逻辑从应用代码（jQuery 和后端语言）中剥离，转移到了基础设施层，它不仅解决了跨域，还能方便地处理负载均衡、缓存和 HTTPS 统一管理，对于大型企业级应用，这是最推荐的架构实践。
归纳与最佳实践建议
在处理 jQuery 二级域名交互时，不应盲目使用 document.domain，如果项目是遗留系统且大量依赖 iframe 交互，document.domain 是快速修复的手段，但对于新项目或标准的 Ajax 数据请求，应坚决采用 CORS 或 Nginx 反向代理。
从 SEO 和用户体验的角度来看，使用 Nginx 反向代理可以减少前端 HTTP 请求的复杂度，避免预检请求带来的延迟，从而提升页面加载速度，而从安全角度看，CORS 提供了细粒度的权限控制，远优于 JSONP 或放宽 document.domain，开发者应根据项目的实际架构阶段，选择最合适的技术路径，确保在解决跨域的同时,不引入新的安全隐患。
相关问答
Q1：设置了 document.domain 后，jQuery 的 Ajax 请求就一定能成功吗？
A： 不一定。document.domain 主要解决的是不同窗口或 iframe 之间的 DOM 访问权限问题，在现代浏览器（如 Chrome、Firefox）的高安全策略下，即使设置了 document.domain，Ajax 请求依然可能受到同源策略的拦截，要解决 Ajax 跨域，最稳妥的方法依然是服务端开启 CORS 或使用反向代理，单纯依赖 document.domain 无法完全解决 XHR（XMLHttpRequest）的跨域限制。
Q2：JSONP 方案现在还适合用于解决二级域名跨域吗？
A： 不推荐，JSONP 虽然能解决跨域，但它存在明显的缺陷：它只支持 GET 请求，无法传输大量数据或执行写操作；JSONP 存在 XSS 安全风险，因为回调函数的执行内容完全由服务端控制，相比之下，CORS 支持所有 HTTP 方法且安全性更高，Nginx 反向代理则对前端完全透明，除非需要兼容非常老旧的浏览器（如 IE6），否则不应在二级域名通信中使用 JSONP。
互动
你在实际的项目开发中，是倾向于使用 Nginx 统一代理接口，还是直接在前端处理跨域？欢迎在评论区分享你的架构选择和遇到的坑。
