一個場景
你做為項目前端的負責人，需要定下前端的數據請求規范與框架，你早就對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是最好的處理方式。