摘要：首先糾正一個誤區，跨域并非瀏覽器限制了發起跨站請求的這種能力，恰恰相反，我們可以發出請求，服務端也可以接收到請求并正常返回數據，只不過在返回之后瀏覽器會阻止非同源數據，從而在控制臺打出一系列報錯信息。

首先糾正一個誤區，跨域并非瀏覽器限制了發起跨站請求的這種能力，恰恰相反，我們可以發出請求，服務端也可以接收到請求并正常返回數據，只不過在返回之后瀏覽器會阻止非同源數據（response），從而在控制臺打出一系列報錯信息。
原文地址：說說跨域那些事兒，遷移到簡書上來和大家共享

文章中會涉及一系列兼容性的圖解（mdn & can i use）和一些專有名詞（mdn），可以通過兩個渠道來查看

Can I Use

MDN

定義就不說了，從字面也可以看其含義，首先我們認識下哪些情況屬于跨域，可以分為以下幾點：

協議不同，如http, https；

端口不同；

主域相同，子域不同；

主域不同；

ip地址和域名之間也算是跨域，瀏覽器不會自動做ip域名的映射；

document.domain

window.name

jsonp

postMessage

cors

關鍵點

跨域分為兩種，一種xhr不能訪問不同源的文檔，另一種是不同window之間不能進行交互操作;

document.domain主要是解決第二種情況，且只能適用于主域相同子域不同的情況；

document.domain的設置是有限制的，我們只能把document.domain設置成自身或更高一級的父域，且主域必須相同。例如：a.b.example.com中某個文檔的document.domain可以設成a.b.example.com、b.example.com 、example.com中的任意一個，但是不可以設成c.a.b.example.com，因為這是當前域的子域，也不可以設成baidu.com，因為主域已經不相同了。

兼容性：所有瀏覽器都支持；

優點：

可以實現不同window之間的相互訪問和操作；

缺點：

只適用于父子window之間的通信，不能用于xhr；

只能在主域相同且子域不同的情況下使用；

使用方式

a（當前頁面或父頁面）頁面中加入document.domain = "example.com";

b（當前頁面或子頁面）頁面中加入document.domain = "example.com";

a頁面訪問b頁面里面的數據或者方法；

關鍵點：window.name在頁面的生命周期里共享一個window.name;

兼容性：所有瀏覽器都支持；

優點：

最簡單的利用了瀏覽器的特性來做到不同域之間的數據傳遞；

不需要前端和后端的特殊配制；

缺點：

大小限制：window.name最大size是2M左右，不同瀏覽器中會有不同約定；

安全性：當前頁面所有window都可以修改，很不安全；

數據類型：傳遞數據只能限于字符串，如果是對象或者其他會自動被轉化為字符串，如下；

使用方式：修改window.name的值即可；

關鍵點：瀏覽器對XHR做了同源策略，但并沒有將這種方式延續到script上（其實還有iframe，img等），從而可以利用動態script標簽技術來做到跨域請求的作用。至于為什么會這樣設計，本人也不太清楚，有可能是歷史遺跡（漏洞），有可能是某些方面的技術瓶頸，也有可能是為了滿足某些需求專門定制的，總之這項技術方案我們過去可以用，現在可以用就ok，至于將來應該也是會存在的，畢竟現在已經應用在很多家站點上，就算會廢棄，也會有一段時間迭代。

兼容性：所有瀏覽器都兼容這種方式；

優點：很明顯前端可以很輕松的做到跨域請求；

缺點

只能通過GET方式請求，一方面是參數長度有限制，二是安全性比較差；

后端需要知道前端的cb是什么樣的結構，主要在參數和回調名；

后端需要進行參數和cb的拼接然后才能執行；

使用方式

/** 前端生成script標簽，并將src中傳入需要執行的callback **/



/** 后端接到參數后給callback加入參數并執行 **/

關鍵點：postMessage是h5引入的一個新概念，現在也在進一步的推廣和發展中，他進行了一系列的封裝，我們可以通過window.postMessage的方式進行使用，并可以監聽其發送的消息；

兼容性：下圖是postMessage的兼容圖，移動端可以放心用，但是pc端需要做降級處理，具體可以根據文中介紹的這幾種跨域方式來則情選擇；

優點

不需要后端介入就可以非常簡單的的做到跨域，一個函數外加兩個參數（請求url，發送數據）就可以搞定；

移動端兼容性好；

缺點

無法做到一對一的傳遞方式：監聽中需要做很多消息的識別，由于postMessage發出的消息對于同一個頁面的不同功能相當于一個廣播的過程，該頁面的所有onmessage都會收到，所以需要做消息的判斷；

安全性問題：三方可以通過截獲，注入html或者腳本的形式監聽到消息，從而能夠做到篡改的效果，所以在postMessage和onmessage中一定要做好這方面的限制；

發送的數據會通過結構化克隆算法進行序列化，所以只有滿足該算法要求的參數才能夠被解析，否則會報錯，如function就不能當作參數進行傳遞；

使用方式：下面是前段時間寫的一個通信的函數，sendMessage_負責發送消息，bindEvent_負責消息的監聽并處理，可以通過代碼來做一個大致了解；

Storage.prototype.sendMessage_ = function(type, params, fn) {
    if (this.topWindow) {
        this.handleCookie_(type, params, fn);
        return;
    }
    var eventId = this.addToQueue_(fn, type);
    var storageIframe = document.getElementById("mip-storage-iframe");
    var element = document.createElement("a");
    element.href = this.origin;
    var origin = element.href.slice(0, element.href.indexOf(element.pathname) + 1);        

    storageIframe.contentWindow.postMessage({
        type: type,
        params: params,
        eventId: eventId
    }, origin);
}

Storage.prototype.bindEvent_ = function() {
    window.onmessage = function (res) {
        // 判斷消息來源            
        if (window == res.source.window.parent &&
            res.data.type === this.messageType.RES &&
            window.location.href.match(res.origin.host).length > 0) {                
            var fn = this.eventQueue[res.data.eventId];
            fn && fn();
            delete this.eventQueue[res.data.eventId];
            // reset id
            var isEmpty = true;
            for (var t in this.eventQueue) {
                isEmpty = false;
            }
            if (isEmpty) {                    
                this.id = 0;
            }
        }                    
    }.bind(this);
}

關鍵點：cors是一種通過前后端http header配置來進行跨域的一種方式；

兼容性：如果不考慮pc端的IE，移動端的opera的話那兼容性還是不錯的，針對ie和opera可以做適當的降級處理；

安全策略

請求

origin：通過http頭中的origin判斷域名是否是允許的；

Example-Same-origin：如果http origin不存在，最好能夠自己在請求頭中加入該參數來標示是否是同源，true表示請求來自于同域名下（同域名下請求不帶origin）；如果該字段存在并且為true則允許請求接口，否則禁止；

Example_source_origin：該參數同origin，是在origin不存在的情況下用來標示請求來源的url；

返回

Access-Control-Allow-Origin: origin，origin表示允許哪些網站請求，不建議設置為*；

Access-Control-Expose-Headers:Example-Access-Control-Allow-Source-Origin，允許http返回中包含該字段，可以通過這種方式在返回頭中加入自定義字段，如該例子中的Example-Access-Control-Allow-Source-Origin;

優點

前端方便不少，只需要發請求而不用考慮跨域問題；

安全性能夠得以控制和保障；

缺點

兼容性不全面，需要做降級處理；

使用方式

正常請求即可，無論是你要用xhr，還是用一些封裝好的組件，如fetch，fetchJsonp，亦或是jquery一類的技術均可；

后端在response時需要設置一定的配置參數，并保證安全策略，具體方案可以參照下面安全策略模塊；