JS跨域知識總結：
在"跨域"一詞經常性地出現以前，我們其實已經頻繁地使用它了。如在A網站的img，
src指向B網站的某一圖片地址，毫無疑問，這在通常情況下都是能正常顯示的（且不論防盜鏈技術）；
同樣，可以使script標簽的src屬性指向其它網站的腳本資源
（在某些情況下甚至鼓勵這樣做，以便充分利用其它網站的負載優勢，減小自身服務器的并發量）。
然而，如若使用js去主動請求其它網站的數據，
比如ajax方式，就會遇到讓人郁悶的跨域問題，這也是我們平常所說的跨域。
由于安全原因，跨域訪問是被各大瀏覽器所默認禁止的。這里涉及到同源策略的概念：
同源策略阻止從一個域上加載的腳本獲取或操作另一個域上的文檔屬性。
也就是說，受到請求的 URL 的域必須與當前 Web 頁面的域相同。
這意味著瀏覽器隔離來自不同源的內容，以防止它們之間的操作。
跨域帶來的具體安全問題博主沒有深究，大伙可以自行腦補。
然而，很多情況下，特別是在互聯網持續發展的今天，我們需要請求來自不同合作伙伴或
數據提供商的前端接口，在跨域訪問的方式沒有規范化前（client端跨域訪問的需求看來也
引起w3c的注意了，看資料說html5 WebSocket標準支持跨域的數據交換，應該也是一個將來可選
的跨域數據交換的解決方案），有什么方法能繞過它的限制呢？答案有很多
（雖然都很麻煩），最常用的當屬所謂的JSONP跨域了。
JSONP原理
JSONP的最基本的原理是：動態添加一個<script>標簽，而script標簽的src屬性是沒有跨域的限制的。
這樣說來，這種跨域方式其實與ajaxXmlHttpRequest協議無關了。
JSONP即JSON with Padding。由于同源策略的限制，XmlHttpRequest只允許請求當前源
（域名、協議、端口）的資源。如果要進行跨域請求，我們可以通過使用html的script標記來進行
跨域請求，并在響應中返回要執行的script代碼。 這種跨域的通訊方式稱為JSONP。
來個簡單的例子：
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <title>Test Jsonp</title> <script type="text/javascript"> function jsonpCallback(result) { alert(result.msg); } </script> <script type="text/javascript" src="http://crossdomain.com/
jsonServerResponse?jsonp=jsonpCallback"></script> </head> <body> </body> </html>
簡述原理與過程：首先在客戶端注冊一個callback, 然后把callback的名字傳給服務器
（這里客戶端和服務器約定以key為jsonp的查詢字符串值傳遞）。此時，服務器先生成 json 數據。
然后以 javascript 語法的方式，生成一個function , function 名字就是傳遞上來的參數 jsonp。
最后將 json 數據直接以入參的方式，放置到 function 中，這樣就生成了一段 js 語法的文檔，
返回給客戶端。客戶端瀏覽器，解析script標簽，并執行返回的 javascript 文檔，
即執行了預定義的callback函數。
從上述簡述可以推出：除了返回函數形式的js代碼片段，服務端自然能返回所有符合規范的可執行js片段。
JSONP的缺點是：它只支持GET請求而不支持POST等其它類型的HTTP請求；它只支持跨域HTTP請求這種情況，
不能解決不同域的兩個頁面之間如何進行JavaScript調用的問題。（下面還有）
jQuery的Jsonp
如前所述，jsonp并非ajax請求，但是jQuery仍提供與jQuery.ajax一致的方式進行跨域請求：
$.ajax({
url: ’http://crossdomain.com/jsonServerResponse’,
type: ’GET’,
dataType: ’jsonp’,
jsonp: "callback",
jsonpCallback: ’functionName’,
success: function (data, textStatus, jqXHR) { }
//……
});
如上所示，dataType設為jsonp表示這是一次跨域請求，jsonp設為服務端預定的
傳遞函數名稱的查詢字符串key，而jsonpCallback即為js函數名稱；假如jsonpCallback不設置，
那么jQuery將自動生成的隨機函數名（在window對象中加載一個全局的函數，
當代碼插入時函數執行，執行完畢后就會被移除），可推斷該自動生成的函數會回調上述代碼中的success函數。
（當手動為jsonpCallback賦值時，不知道success函數會否回調，
還是說jQuery會尋找預定義的函數，若找不到則報錯？博主懶，以后再試吧。）
當然jQuery為我們提供了一個簡易版本，$.getJSON，這里就不贅述了。
需要注意的是success函數中的jqXHR參數，在ajax請求中，它是正宗的jqXHR對象，
亦可看作是XMLHTTPRequest對象（繼承or封裝），但是在jsonp請求中卻并非如此，
幾乎不能帶給我們如XMLHTTPRequest中最有用的那些信息：
它缺少XMLHTTPRequest的請求狀態信息，所以并不能觸發絕大部分的回調函數，
比如error、complete等（jQuery1.9.0），
而可以被回調的success函數推測應該是由script標記的load事件觸發，
這也同ajax依靠XMLHTTPRequest的狀態的機制完全不同。經試驗，
脫胎于jQuery的zepto（v1.1.3），在jsonp請求出現錯誤，
比如加載js文檔時頭部返回401錯誤時，error函數會執行，但是該函數的jqXHR參數也同樣不是正宗的
jqXHR類型，甚至不能通過它獲取響應的頭部信息，在這種情況下，我們只是被告知某個環節出錯了，
卻并不知道具體的錯誤信息。類似響應頭承載有用信息的場景，博主不建議使用jsonp，可以說，
使用jsonp的一個前提是：除了網絡異常等非業務異常外，所有業務異常（概括地說，
乃是從服務器接收請求到返回響應這段時間內拋出的所有異常）都需要以請求結果的形式直接返回給客戶端，
便于客戶端回調分析。
感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！
【 微信掃一掃 】
