徐紫诺
- 首先jsonp可扩展性不好，针对业务逻辑进行扩展应该有自己的统一api管理
- jsonp需要服务端配合你，你传给服务端是自定义callback，服务端需要处理这些传过来的回调，而且不利于前后端分离
- 可能造成安全问题(跨站脚本攻击)
- 前端自己维护起来也费劲，而且对异步网络io来讲，使用嵌套回调来控制异步任务显然是不明智的举措
KKXIAO
一个场景
你做为项目前端的负责人，需要定下前端的数据请求规范与框架，你早就对axios很不满了，于是决定拉起袖子，直接用JSONP上。
于是在团队里面，你直接喊，大家，后面我们请求数据统一使用JSONP，谁用axios谁明天就不用来了。
然后，你和服务端的人员开了一个会，让他们定下接口文档，一天后，你收到一份接口文档，里面写好了请求协议，除了GET还有POST，还有PUT和DELETE。
你用了一个GET接口，请求完，发现很完美，服务端不用设置Access-Control-Allow，你突然觉得自己这个决定很完美，果然最初的决定是正确的，于是你就让各个开发开始对接服务端接口。
问题来了
不一会儿，一位前端开发和你说，不行呀，JSONP只能进行Get请求，其它什么POST都不支持呀，顿时你懵逼了……
上面是个虚拟场景，里面讲了JSONP的一个问题，就是只能使用GET请求获取数据。我们来细说下什么是JSONP。
JSONP原理
ajax的核心是通过XmlHttpRequest获取链接的内容，它是可以支持任何请求方式的。但有个问题就是，如果服务端不支持，它是不可能取到跨域请求的信息的。而JSONP呢？
我们在写网页代码时，发现标签的src属性是可以加载其它跨的信息的，比如Script、Img、iFrame的标签，于是我们灵机一动，那是不是也可以来加载服务端接口呀。
然后你试了下，哇靠，果然可以，只要输出格式处理好，你甚至可以使用它来请求数据并进行处理。
先天问题
但是由于先天性的问题，JSONP只适合用来获取数据，它没法做其它请求处理。
那你可能会说，那我就获取使用JSONP可以了吧，其它使用AJAX。我们先不说，统一编码对维护性的成本降低的重要性，你还分两套实现方案，你如果实在要处理，我们试下看看效果如果。
假如一切正常，你用JSONP请求数据，数据返回正常，你显示，很完美。
假如出了一点点问题，你用JSONP请求数据，数据没返回，或是一些奇怪的错误，对，没有错误码，你都不知道是网络问题，还是代码问题，还是鉴权问题。对了，说到鉴权，JSONP你都没法自定义Header，可制作性太低了。
总结下
- JSONP请求能力单一
- JSONP在现在前端开发中影响编码规范
- 现在跨域处理很方便，处理都是微服务
例外
如果你实在需要一个外部接口，这个接口不是你开发的，且是不支持跨域的，那JSONP是最好的处理方式。
一颗萝卜啊
题主概念混淆了，axios和jsonp并不是解决同一问题的东西
axios是一种ajax请求的封装
而jsonp是一种跨域ajax请求的解决方案
所以说就算是你用axios一样会有跨域问题，而遇到跨域的问题之后，你可以选择使用jsonp/proxy代理的方式把这个跨域的问题解决掉。
两者本质上并不冲突
