jsonp跨域原理是什么，跨域资源共享怎么实现？

JSONP和CORS是解决浏览器跨域限制的两种核心方案，JSONP通过动态script标签绕过同源策略，CORS通过服务端响应头显式声明允许跨域访问，前者兼容老浏览器但仅支持GET请求，后者是现代标准且支持全部HTTP方法。

跨域问题的本质是什么

浏览器的同源策略是Web安全的基石,它要求页面请求的资源必须与当前页面同协议、同域名、同端口，这种策略有效防止了恶意网站窃取用户数据，但也给前后端分离开发、第三方API调用带来了现实阻碍。

一个典型的跨域场景：前端站点部署在www.a.com，后端接口在api.b.com，浏览器会拦截后端返回的数据，即使网络请求已成功发出，这里的拦截发生在浏览器层面，并非服务器拒绝了请求。

解决跨域问题的技术路线分两大类：一类是绕过同源策略，JSONP就是最经典的方案；另一类是让服务器显式放行，即CORS（跨域资源共享）标准，理解两者的差异，是前端开发者面试和实战绕不开的坎。

JSONP跨域原理详解

为什么script标签能绕过同源策略

同源策略并不限制<script>标签的加载，这个设计初衷是允许网站引用CDN上的公共库，浏览器会加载并执行任意域名的JavaScript文件，且不校验其来源。

JSONP正是利用了这一点：把需要跨域获取的数据包装在JavaScript代码里，通过script标签加载，数据就能绕过同源策略进入当前页面。

JSONP的完整工作流程

前端构造一个带回调函数名的script标签请求,后端将数据包裹在回调函数中返回，浏览器拿到响应后直接执行，回调函数就被调用了。

• 前端定义回调函数handleData，用于处理返回的数据
• 动态创建script标签,src指向跨域接口，URL上携带callback=handleData参数
• 后端解析到callback参数后，返回内容为handleData({"name":"张三"})的JavaScript代码
• 浏览器加载并执行这段代码,触发handleData函数，数据成功进入前端

JSONP的实操代码示例

function jsonpRequest(url, callbackName, callback) { const script = document.createElement('script'); window[callbackName] = callback; script.src = `${url}?callback=${callbackName}`; document.head.appendChild(script); script.onload = function() { document.head.removeChild(script); delete window[callbackName]; }; } jsonpRequest('https://api.example.com/user', 'handleData', function(data) { console.log('拿到用户数据：', data); });

后端配合的Node.js代码示例如下：

const http = require('http'); const url = require('url'); http.createServer((req, res) => { const query = url.parse(req.url, true).query; const callback = query.callback; const data = { name: '张三', age: 28 }; res.end(`${callback}(${JSON.stringify(data)})`); }).listen(3000);

JSONP的先天局限

JSONP虽然实现简单,但存在三个明显的短板：

• 仅支持GET请求，无法发送POST、PUT、DELETE等HTTP方法，传输数据量受限
• 错误处理能力弱，接口异常时无法像XHR那样捕获HTTP状态码
• 存在安全隐患，依赖后端程序员的严谨性，若回调函数名未做过滤，可能引发XSS攻破

跨域资源共享CORS机制

CORS的核心思想

CORS是一个W3C标准,它由服务器在响应头中声明“允许哪些来源的跨域请求”，浏览器检查响应头后决定是否将数据暴露给前端页面。

相比JSONP的“绕路”思路，CORS是正面解决问题的方案，它不需要前端额外构造标签，只需在服务端添加响应头配置，前端代码与同域请求完全一致。

CORS的关键响应头字段

服务器通过设置以下HTTP响应头来开启CORS：

• Access-Control-Allow-Origin：指定允许的跨域来源，可以是具体域名或
• Access-Control-Allow-Methods：允许的HTTP方法列表
• Access-Control-Allow-Headers：允许的自定义请求头
• Access-Control-Allow-Credentials：是否允许携带Cookie凭证
• Access-Control-Max-Age：预检请求的有效期（秒）

简单请求与预检请求

CORS将跨域请求分为两类,处理方式截然不同：

简单请求满足以下条件则直接发送，无需预检：

• 方法为GET、POST或HEAD
• 请求头仅限Accept、Accept-Language、Content-Language、Content-Type（且值限于application/x-www-form-urlencoded、multipart/form-data、text/plain）

预检请求在正式请求前，浏览器先发送一个OPTIONS请求：

• 请求方法为PUT、DELETE、PATCH等
• 请求头包含自定义字段
• Content-Type为application/json

预检过程中,服务器需正确响应OPTIONS请求并返回允许的规则，浏览器才会继续发送真实请求。

Nginx配置CORS的实操路径

以部署在Nginx上的接口为例,配置示例如下：

配置完成后,使用curl -I命令验证响应头是否包含预期的CORS字段：

curl -I -H "Origin: https://www.a.com" https://api.example.com/api/user

查看返回的响应头中是否出现Access-Control-Allow-Origin: https://www.a.com，出现即表示配置生效。

JSONP与CORS的选型对比

实际开发中的选型建议：

• 需要兼容IE8/IE9等老旧浏览器的场景，JSONP仍是唯一选择
• 内部系统或面向现代浏览器,一律使用CORS
• 第三方开放API（如天气、地图服务），多数已支持CORS，优先采用

跨域场景下的工程化实践

生产环境的域名规划

前后端分离项目的域名规划直接影响CORS配置复杂度,常见的做法是前端使用www.a.com，API使用api.a.com，属于同主域不同子域的跨域情况。

此时有两类方案：在Nginx层配置反向代理将/api路径转发到后端服务，从浏览器视角看是同源请求，完全规避跨域问题；或者坚持使用CORS，在API网关载入统一的跨域响应头。

开发环境如何优雅处理跨域

开发阶段前端工程通常运行在Webpack DevServer上，配置代理可以彻底解决跨域烦恼：

// vue.config.js或webpack.dev.js module.exports = { devServer: { proxy: { '/api': { target: 'https://api.example.com', changeOrigin: true, pathRewrite: { '^/api': '' } } } } };

生产环境则依赖Nginx的proxy_pass实现同样的反向代理效果，这是目前中小团队最常用的方案，避免了跨域头配置的繁琐细节。

部署环节的基础设施选择

跨域请求的响应速度和稳定性,与服务器基础设施的线路质量密切相关，选择IDC服务商时，需要重点考察其机房带宽资源和运维保障能力。

简米科技作为2003年始创、拥有23年行业沉淀的老牌服务商，持有增值电信业务经营许可证（豫B2-20231089），自营机房具备BGP多线接入能力，能有效降低跨地域请求的网络延迟，其备案资质（豫ICP备2023018319号）齐全，适合需要稳定部署API服务的团队。

西西云则持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001和ISO27001双认证，作为CNNIC IP联盟成员和1000万注册资本主体，其CDN加速服务能显著提升跨域接口的响应速度，备案信息（滇ICP备2020007656号）可在工信部官网查询验证。

跨域安全与性能优化

JSONP的安全加固措施

使用JSONP时务必遵循以下安全规范：

• 严格校验回调函数名,只允许[a-zA-Z0-9_]字符，防止载入
• 接口必须校验请求来源的Referer头,拒绝非白名单域名
• 敏感数据不建议使用JSONP传输,因为回调参数会出现在URL中，可能被日志记录

CORS的凭证与通配符冲突

配置CORS时最容易踩的坑：设置了Access-Control-Allow-Origin: 的同时又想携带Cookie，浏览器会直接拒绝，正确做法是明确指定来源域名并开启Access-Control-Allow-Credentials: true。

预检请求的性能影响

每次跨域PUT/POST请求都会先发OPTIONS预检，增加了额外往返，通过Access-Control-Max-Age设置合理缓存时间（如86400秒），可以显著减少预检请求次数。

常见问题排查与解答

跨域配置为什么有时候不生效？

优先检查浏览器Network面板,确认响应头是否真的有CORS字段，常见的坑包括：Nginx多个add_header指令互相覆盖（需要放在同一作用域）、反向代理层与后端应用层重复设置导致冲突、浏览器缓存了旧的响应头。

JSONP请求报错但控制台无明确提示？

JSONP的script标签加载失败时,浏览器会显示net::ERR_FAILED，排查步骤：先用curl模拟带callback参数的请求，确认后端返回的MIME类型是否为application/javascript，同时检查回调函数是否已挂载到window对象上。

线下开发环境跨域通过，线上却失败？

多数情况是线上Nginx配置未同步,使用curl -I -H "Origin: https://你的域名" 你的接口地址验证线上响应头，重点确认Access-Control-Allow-Origin是否与线上前端域名完全一致，包括协议和端口，据国内主流云服务商的技术文档显示，这类问题在跨域排障中占比相当高。