JavaScript跨域核心靠服务端配合，前端无法绕过同源策略；主要方式为CORS（现代标准，支持全HTTP方法、凭证、预检）和JSONP（历史方案，仅GET、无错误捕获、有XSS风险）。
JavaScript处理跨域请求主要靠服务端配合，前端无法绕过同源策略。核心方式是CORS（现代标准方案）和JSONP（历史兼容方案），两者原理、适用场景和限制完全不同。
CORS：服务端显式授权的现代标准
CORS（Cross-Origin Resource Sharing）是W3C标准，依赖HTTP响应头控制浏览器是否允许跨域访问。关键在于服务端必须返回正确的响应头，如 Access-Control-Allow-Origin，否则浏览器直接拦截响应（即使请求已发出、服务器也成功返回数据）。
- 支持所有HTTP方法（GET/POST/PUT/DELETE等），不仅限于读取
- 可携带Cookie、认证头（需设置 credentials: true 且服务端明确允许）
- 预检请求（OPTIONS）自动触发：当请求含自定义头、非简单Content-Type或非简单方法时，浏览器先发OPTIONS探路
- 前端用fetch或XMLHttpRequest即可，无需特殊封装；例如：
fetch('https://api.example.com/data', { credentials: 'include' })
JSONP：利用script标签绕过限制的旧方案
JSONP（JSON with Padding）不是标准协议，而是利用
- 只支持GET请求，无法发送POST或带body的数据
- 无错误捕获机制：script加载失败（404、超时、语法错误）只能靠timeout模拟，无法区分具体原因
- 完全依赖服务端配合返回函数调用格式，且前端需提前定义好回调函数名
- 存在XSS风险：执行远程脚本等于信任对方代码，不适用于不可信源
关键区别总结
根本差异在于通信机制和控制权归属：
立即学习“Java免费学习笔记（深入）”；
- CORS由浏览器强制执行，服务端通过响应头声明权限；JSONP由开发者手动构造script标签，本质是“骗过”同源策略
- CORS可精确控制（哪些源、哪些方法、是否带凭证）；JSONP只有“允许执行”或“不允许”，粒度粗
- 现代项目应优先使用CORS；JSONP仅用于极老系统或无法修改服务端响应头的遗留场景
- 注意：CORS失败时控制台报错明显（如“Blocked by CORS policy”）；JSONP失败往往静默，需主动监听error事件或设超时
