简单说就是，将某JS方法的声明和调用分别交给前端和后端，通过实参与形参间的传值实现前后端通信。

这个方案乍看之下似乎有两个问题，一个是这个“JS方法”是如何实现前后端同步的？

再就是后端服务器上的动态脚本执行环境怎么能调用前端浏览器上声明的JS方法呢？

这里先回答第二个问题。那就是在这个情景下，说JS方法由后端调用，并不等于说执行也是后端在做。

事实是，虽然调用是后端，但执行其实还是在前端浏览器中。

而实现这种调用与执行的分离，以及实现“JS方法”的同步，都是靠的一个相同的手段，那就是HTML的 script 标签。

这个script标签原本是用来通过http请求加载静态的JavaScript脚本资源的。可是某个老六突发奇想，用script加载起动态的JavaScript脚本，然后就诞生了JSONP的通信方式。

这里说的所谓“静态的JavaScript脚本资源”，说的是放在服务器磁盘上一成不变的JavaScript文本资源，谁请求都是得到一个相同的副本，就像提前做好的预制菜一样。

而所谓“动态的JavaScript脚本资源”，就是说JavaScript文本资源并不是现成的，请求实际是发向一个后端运行的“动态脚本”，比如PHP、JSP之类的。然后JavaScript脚本则是由这些后端脚本再根据具体情况按需生成，整体而言就像“点菜现炒”。

具体说就是，这个“后端脚本”会根据http请求的具体参数的不同响应返回不同的JavaScript脚本文本给浏览器端来执行。

于是，那个计划由“前端声明后端调用”的JS方法的方法名便由前端创建，并由script标签发起的http请求的get参数同步给了后端。

接着，后端脚本则根据得到的JS方法名拼接一个对该方法进行调用的JavaScript脚本片段，并将要传输给前端的数据作为此次调用的实参。

最后，这个由后端拼接的、带着实参的“JS方法调用片段”便通过前端script标签发起的http请求的响应报文从服务器返回给浏览器，并在浏览器端自动执行。

最终，在执行的过程中，后端的数据便通过JS方法调用时的实参传递给了JS方法声明时的形参，进而进入回调函数，然后执行具体的前端渲染逻辑。

JSONP的流行主要是为了绕过浏览器的“同源策略”，实现跨域请求。相比于CORS这种更标准和简洁的方案，它的优点就是兼容性好，不管多老的版本，只要支持JS的浏览器都支持JSONP。

-END-

阅读原文：原文链接