今天来跟大家讲讲故事，一个人很心酸的故事，jsonp是什么？
故事的背景起源于我们主管要求我完善的一个功能，在登录接口401的时候跳转登录页面，其实讲道理这应该是个很简单的功能，但是我打开我的代码瞅了一眼，发现我天，我的接口请求都是jsonp的，我去，我真心不知道jsonp怎么拿到请求状态码。。。一脸懵逼，于是就开始问度娘，搜索了好多页的关键词，终于看到了希望，同时也看到了绝望。。。
jsonp有很多缺陷的，比如：
1，不能接受HTTP状态码
2，不能使用POST提交（默认GET）
3，不能发送和接受HTTP头
4，不能设置同步调用（默认异步）
...
其最严重的就是不能提供错误处理，如果请求的代码正常执行那么会得到正确的结果。如果请求失败，如404,500之类，那么可能什么都不会发生。
这是我看到的一篇博客上的原话，我仔细思考了一下，确有道理。
再往下看它的解决方法哈：onerror
IE9/10/Firefox/Safari/Chrome都支持script的onerror事件，如果请求失败，在onerror上可以进行必要的回调处理，但是，程序猿最怕但是，一听到这句话就感觉是兼容，omg，兼容问题，所以在IE6/7/8/Opera不支持onerror
最后这位博主给了最详细的解决方法：
1，IE9/Firefox/Safari/Chrome 成功回调使用onload事件，错误回调使用onerror事件
2，Opera 成功回调也使用onload事件（它压根不支持onreadystatechange），由于其不支持onerror，这里使用了延迟处理。即等待与成功回调success，success后标志位done置为true。failure则不会执行，否则执行。这里延迟的时间取值很有技巧，之前取2秒，在公司测试没问题。但回家用3G无线网络后发现即使所引用的js文件存在，但由于网速过慢，failure还是先执行了，后执行了success。所以这里取5秒是比较合理的。虽然这种方式间接实现了failure，但不彻底。
3，IE6/7/8成功回调使用onreadystatechange事件，错误回调几乎是很难实现的。令人恶心的是即使请求的资源文件不存在（404）。它的readyState也会经历“loaded”状态。这样你就没法区分请求成功或失败。最后使用前后台一起协调的机制解决最后的这个难题。无论请求成功或失败都让其调用callback(true)。 此时已经将区别成功与失败的逻辑放到了callback中，如果后台没有返回jsonp则调用failure，否则调用success。
其实说了这么多，总结出来就一句话，如果你要使用jsonp一定要知道并接受它的缺点，因为你只能适应它，最好的方式就是尽量不要使用jsonp，跨域这块交给后端来解决，那样前端就可以使用一些axios、fetch、http等框架来发送请求，你就能正常的拿到你想要的状态码等一系列vip待遇。
好了，你们觉得我最后怎么解决这个问题的呢？😂
参考地址：https://www.cnblogs.com/zhouchaoyi/articles/2085924.html
