Ajax 基于 XMLHttpRequest 对象实现同域或跨域数据交互，而 JSONP 利用 script 标签的跨域特性通过回调函数获取数据，前者支持所有 HTTP 方法且更现代，后者仅支持 GET 请求且为早期跨域解决方案。
在 Web 开发的漫长演进中，前端与后端的数据握手方式经历了从粗暴到精细的变革，理解 Ajax 与 JSONP 的区别，不仅是掌握两个技术名词，更是理解浏览器安全策略（同源策略）如何一步步被突破和规范的缩影，对于开发者而言,选择哪种方案取决于目标浏览器的兼容性要求以及当前项目的架构复杂度。
Ajax 与 JSONP 的核心机制差异
要厘清两者的本质区别，必须回到它们的技术底层，Ajax（Asynchronous JavaScript and XML）并非单一技术，而是多种技术的组合，其核心在于 XMLHttpRequest 对象，这个对象允许网页在无需刷新整个页面的情况下,与服务器进行少量数据的交换。
同源策略下的 Ajax 限制
Ajax 的强大建立在浏览器的“同源策略”之上，所谓同源，是指协议、域名和端口号完全相同，如果前端页面位于 http://www.example.com，而试图通过 Ajax 请求 http://api.other.com 的数据，浏览器出于安全考虑，默认会拦截该请求，抛出跨域错误，这一机制有效防止了 CSRF（跨站请求伪造）等攻击,但也给数据集成带来了巨大障碍。
JSONP 的“曲线救国”策略
JSONP（JSON with Padding）的出现，是为了解决上述跨域问题而诞生的“黑客式”方案，它利用了 HTML 中 <script> 标签的一个特性：script 标签不受同源策略限制。
JSONP 的工作流程如下：
- 前端定义一个全局回调函数，
handleResponse(data)。 - 前端动态创建一个
<script>标签，其src属性指向后端接口，并携带回调函数名作为参数，如?callback=handleResponse。 - 后端接收请求，将数据包裹在回调函数中返回，
handleResponse({ "name": "test" })
。
- 浏览器执行这段脚本，从而触发前端定义的回调函数,完成数据接收。
这种机制本质上是将数据交互伪装成了脚本加载，虽然巧妙,但存在明显的安全隐患和局限性。
技术特性与适用场景深度对比
在实际项目中，选择 Ajax 还是 JSONP，往往取决于具体的业务场景和技术栈,以下是两者在关键维度上的详细对比。
请求方法与数据格式
Ajax 基于 XMLHttpRequest 或现代浏览器支持的 Fetch API，支持 GET、POST、PUT、DELETE 等多种 HTTP 方法，这意味着你可以发送复杂的 JSON 数据、文件上传或执行资源删除操作，相比之下，JSONP 仅支持 GET 请求，因为 <script> 标签只能发起 GET 请求，JSONP 返回的数据必须是可执行的 JavaScript 代码，而非标准的 JSON 格式,这限制了数据的结构化程度。
错误处理机制
Ajax 提供了完善的错误处理机制，通过 onerror 事件或 Promise 的 catch 方法，开发者可以捕获网络错误、超时或 HTTP 状态码错误（如 404、500），而 JSONP 的错误处理极为简陋，如果请求失败（如域名错误），浏览器通常不会触发 onerror 事件，导致开发者难以感知请求失败,只能依靠超时机制进行粗略判断。
安全性考量
JSONP 存在严重的 XSS（跨站脚本攻击）风险，因为后端返回的是可执行的 JavaScript 代码，如果后端被攻击者篡改，返回恶意脚本，前端浏览器将直接执行，导致用户数据泄露或页面被操控，Ajax 虽然也受 XSS 影响，但返回的是纯数据（XML 或 JSON），不会自动执行,安全性相对更高。
| 特性 | Ajax | JSONP |
|---|---|---|
| 跨域支持 | 默认不支持，需后端配置 CORS | 原生支持 |
| HTTP 方法 | GET, POST, PUT, DELETE 等 | 仅 GET |
| 数据格式 | XML, JSON, Text 等 | 仅 JSON (包裹在回调中) |
| 错误处理 | 完善 (onerror, catch) | 较差 (主要靠超时) |
| 安全性 | 较高 (数据不执行) | 较低 (易受 XSS 攻击) |
业内专家指出，随着 HTML5 的普及，JSONP 已逐渐退出历史舞台，但在维护老旧系统或对接不支持 CORS 的第三方老旧接口时，它仍是一剂有效的“止痛药”。
现代跨域解决方案：CORS 与代理
既然 JSONP 如此局限，为什么现在很少再听到它被推荐？答案在于更标准、更安全的跨域解决方案CORS（Cross-Origin Resource Sharing）。
CORS 的工作原理
CORS 是 W3C 标准，通过服务器返回特定的 HTTP 响应头（如 Access-Control-Allow-Origin）来告知浏览器允许哪些源进行跨域访问，前端代码无需任何特殊处理，直接使用标准的 Ajax 或 Fetch 请求即可。
后端 Node.js 服务器可以这样配置：res.setHeader('Access-Control-Allow-Origin', 'http://www.example.com');
这种方式不仅支持所有 HTTP 方法，还允许携带 Cookie 和自定义头信息，安全性远高于 JSONP。
开发环境下的代理方案
在本地开发阶段，为了避免配置复杂的 CORS，开发者常使用 Webpack 或 Vite 的代理功能，通过配置 devServer.proxy，将前端请求转发到后端服务器，从而绕过浏览器的同源策略检查，这是一种开发时技巧，生产环境仍需依赖 CORS 或 Nginx 反向代理。
如何选择：决策指南
面对具体的项目需求，如何做出最优选择？以下是基于场景的决策路径。
现代 Web 应用，后端可控
如果你正在开发一个基于 React、Vue 或 Angular 的现代单页应用，且后端服务器由你或团队控制，强烈建议使用 CORS，这是行业标准，兼容性最好，安全性最高，且支持所有 HTTP 方法，无需考虑 JSONP。
对接老旧第三方 API
如果目标 API 是多年前开发的，不支持 CORS 头，且只提供 JSONP 接口，那么只能使用 JSONP，你需要封装一个工具函数，动态创建 script 标签,并处理超时和错误回退。
IE8/IE9 兼容性问题
虽然 IE 浏览器已逐渐被淘汰，但在某些企业内网系统中，仍可能遇到 IE8/IE9 环境，这些浏览器对 CORS 支持不佳，但支持 JSONP，在这种情况下，JSONP 是唯一的跨域选择，建议通过特性检测，优先使用 Ajax，仅在检测到不支持 CORS 时才降级使用 JSONP。
常见问题解答
Ajax 与 JSONP 的区别及用法有哪些常见误区？
许多初学者认为 JSONP 是一种 Ajax 技术，这是错误的，Ajax 的核心是 XMLHttpRequest，而 JSONP 的核心是 <script> 标签，两者在实现原理、错误处理和安全性上截然不同，JSONP 无法发送 POST 请求，也无法获取响应头信息,这些是常见的认知盲区。
为什么现在不建议使用 JSONP？
主要原因有三：一是安全性差，易受 XSS 攻击；二是功能受限，仅支持 GET 请求；三是现代浏览器和服务器已广泛支持 CORS，提供了更标准、更安全的跨域方案，除非面对无法修改后端的老旧系统，否则 JSONP 已无存在必要。
CORS 配置失败时如何排查？
首先检查浏览器控制台的网络请求，查看响应头是否包含 Access-Control-Allow-Origin，确认后端服务器是否正确配置了该头信息，且允许的来源域名与前端请求一致，对于非简单请求（如包含自定义头或 Content-Type 为 application/json 的请求），浏览器会先发 OPTIONS 预检请求，需确保后端正确处理了 OPTIONS 请求并返回正确的允许头。
Ajax 代表了现代 Web 数据交互的标准方向，而 JSONP 则是特定历史时期的产物，在 2026 年的今天，掌握 CORS 原理并熟练运用标准 Ajax 或 Fetch API，是前端开发者的必备技能，JSONP 仅作为遗留系统的维护手段,不应在新项目中引入。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/ajax%e4%b8%8ejsonp%e5%8c%ba%e5%88%ab%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%9fajax%e8%b7%a8%e5%9f%9f%e8%af%b7%e6%b1%82%e5%a4%b1%e8%b4%a5%e6%80%8e%e4%b9%88%e5%8a%9e/
