Ajax基于XMLHttpRequest对象实现同域或跨域数据交互，而JSONP利用script标签的跨域特性通过回调函数获取数据，前者支持所有HTTP方法且更现代，后者仅支持GET请求且为早期跨域解决方案。
在Web开发的漫长演进中，前端与后端的数据握手方式经历了从粗暴到精细的变革，理解Ajax与JSONP的区别，不仅是掌握两个技术名词，更是理解浏览器安全策略（同源策略）如何一步步被突破和规范的缩影，对于开发者而言,选择哪种方案取决于目标浏览器的兼容性要求以及当前项目的架构复杂度。
要厘清两者的本质区别，必须回到它们的技术底层，Ajax（AsynchronousJavaScriptandXML）并非单一技术，而是多种技术的组合，其核心在于XMLHttpRequest对象，这个对象允许网页在无需刷新整个页面的情况下,与服务器进行少量数据的交换。
Ajax的强大建立在浏览器的“同源策略”之上，所谓同源，是指协议、域名和端口号完全相同，如果前端页面位于http://www.example.com，而试图通过Ajax请求http://api.other.com的数据，浏览器出于安全考虑，默认会拦截该请求，抛出跨域错误，这一机制有效防止了CSRF（跨站请求伪造）等攻击,但也给数据集成带来了巨大障碍。
JSONP（JSONwithPadding）的出现，是为了解决上述跨域问题而诞生的“黑客式”方案，它利用了HTML中<script>标签的一个特性：script标签不受同源策略限制。
JSONP的工作流程如下：
handleResponse(data)。<script>标签，其src属性指向后端接口，并携带回调函数名作为参数，如?callback=handleResponse。handleResponse({"name":"test"})
。
这种机制本质上是将数据交互伪装成了脚本加载，虽然巧妙,但存在明显的安全隐患和局限性。
在实际项目中，选择Ajax还是JSONP，往往取决于具体的业务场景和技术栈,以下是两者在关键维度上的详细对比。
Ajax基于XMLHttpRequest或现代浏览器支持的FetchAPI，支持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的第三方老旧接口时，它仍是一剂有效的“止痛药”。
既然JSONP如此局限，为什么现在很少再听到它被推荐？答案在于更标准、更安全的跨域解决方案CORS（Cross-OriginResourceSharing）。
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反向代理。
面对具体的项目需求，如何做出最优选择？以下是基于场景的决策路径。
如果你正在开发一个基于React、Vue或Angular的现代单页应用，且后端服务器由你或团队控制，强烈建议使用CORS，这是行业标准，兼容性最好，安全性最高，且支持所有HTTP方法，无需考虑JSONP。
如果目标API是多年前开发的，不支持CORS头，且只提供JSONP接口，那么只能使用JSONP，你需要封装一个工具函数，动态创建script标签,并处理超时和错误回退。
虽然IE浏览器已逐渐被淘汰，但在某些企业内网系统中，仍可能遇到IE8/IE9环境，这些浏览器对CORS支持不佳，但支持JSONP，在这种情况下，JSONP是唯一的跨域选择，建议通过特性检测，优先使用Ajax，仅在检测到不支持CORS时才降级使用JSONP。
许多初学者认为JSONP是一种Ajax技术，这是错误的，Ajax的核心是XMLHttpRequest，而JSONP的核心是<script>标签，两者在实现原理、错误处理和安全性上截然不同，JSONP无法发送POST请求，也无法获取响应头信息,这些是常见的认知盲区。
主要原因有三：一是安全性差，易受XSS攻击；二是功能受限，仅支持GET请求；三是现代浏览器和服务器已广泛支持CORS，提供了更标准、更安全的跨域方案，除非面对无法修改后端的老旧系统，否则JSONP已无存在必要。
首先检查浏览器控制台的网络请求，查看响应头是否包含Access-Control-Allow-Origin，确认后端服务器是否正确配置了该头信息，且允许的来源域名与前端请求一致，对于非简单请求（如包含自定义头或Content-Type为application/json的请求），浏览器会先发OPTIONS预检请求，需确保后端正确处理了OPTIONS请求并返回正确的允许头。
Ajax代表了现代Web数据交互的标准方向，而JSONP则是特定历史时期的产物，在2026年的今天，掌握CORS原理并熟练运用标准Ajax或FetchAPI，是前端开发者的必备技能，JSONP仅作为遗留系统的维护手段,不应在新项目中引入。
微信 
电话 
QQ