沒有歸納之前對跨域的一些說法是模糊的寿谴，什么jsonp啊，跨域原理啊疏旨，心里只有一個大概的說法很魂，知道這個東西，然后用的時候直接百度Ctrl+C檐涝，后來閑下來決定整理一波這些知識點遏匆，需知其所以然。

模糊狀態(tài)

什么是跨域

• 域名相同

• 端口號相同

• 協(xié)議相同
  那么以上條件只要有一個不同谁榜，都被當(dāng)作是不同的源幅聘，會出現(xiàn)跨域的問題。
  為什么會出現(xiàn)這個問題呢窃植？因為瀏覽器的同源策略帝蒿。簡單來說：同源策略限制了從同一個源加載的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用于隔離潛在惡意文件的重要安全機制巷怜。這個安全機制大致限制了兩個方面：

• 一是針對接口的請求：CSRF攻擊葛超。某天你登錄了你的銀行賬戶操作XXX，那么在你訪問某些非法網(wǎng)站的時候延塑，如果沒有同源策略巩掺，它向銀行的接口發(fā)起請求（瀏覽器會自動帶上相關(guān)的cookie），假設(shè)銀行的服務(wù)端是根據(jù)cookie來判斷登錄狀態(tài)的話页畦，非法網(wǎng)站就相當(dāng)于登錄了你的銀行賬戶......

• 二是針對Dom的查詢胖替。某天你郵箱收到了一個郵件，說你的銀行賬戶有危險，然后你點擊進去一看独令，跟以前登錄的頁面一模一樣端朵，你立馬輸入了你的賬號密碼......這個頁面其實是一個釣魚網(wǎng)站，里面內(nèi)嵌了一個iframe

<iframe src="某銀行網(wǎng)頁"></iframe>
// 由于沒有同源策略的限制燃箭，釣魚網(wǎng)站可以直接拿到別的網(wǎng)站的Dom
const iframe = window.frames['yinhang']
const node = iframe.document.getElementById('你輸入賬號密碼的Input')
console.log(node) // ok冲呢，拿到密碼，跑路

那么招狸，其實這是瀏覽器對我們的一種保護機制敬拓，把壞人擋在門外。那么裙戏，問題來了乘凸，我們怎么確定門外的人到底是好人還是壞人呢？瀏覽器關(guān)上了壞人的一扇門累榜，留給了我們好人一扇窗营勤。

好人的跨域方式

好人卡

接口請求之JSONP

JSONP跟JSON沒有關(guān)系..就好像JavaScript和Java一樣
瀏覽器對script、img（這些標(biāo)簽的請求方式都是GET壹罚，所以jsonp不支持POST）這種標(biāo)簽沒有限制葛作，我們就可以這樣干

前端代碼
<script type='text/javascript'>
后端返回直接執(zhí)行的方法，相當(dāng)于執(zhí)行這個方法猖凛，由于后端把返回的數(shù)據(jù)放在方法的參數(shù)里赂蠢，所以這里能拿到res。
cb = function(res) {
    console.log(res)
}
</script>
<!-- 傳入數(shù)據(jù)是msg辨泳，傳入一個回調(diào)方式cb -->
<script src='http://xxxxx/api/jsonp?msg=helloWorld&cb=cb' type='text/javascript'></script>

服務(wù)端類似這樣返回
static async jsonp(ctx) {
    // 獲取前端傳入的參數(shù)
    const query = ctx.request.query
    // query.cb獲取到前端傳入的cb字段虱岂。
    // 由于前端是用script標(biāo)簽發(fā)起的請求，
    // 所以前端請求到的資源其實是這樣的一段js代碼  cb(服務(wù)端返回的數(shù)據(jù))漠吻，所以前端就直接執(zhí)行了
    ctx.body = `$ {query.cb} (服務(wù)端返回的數(shù)據(jù))`
}

接口請求之CORS跨域

CORS（Cross-Origin Resource Sharing）跨域資源共享量瓜，定義了必須在訪問跨域資源時司恳，瀏覽器與服務(wù)器應(yīng)該如何溝通途乃。CORS的基本思想就是使用自定義的HTTP頭部讓瀏覽器與服務(wù)器進行溝通，從而決定請求或響應(yīng)是應(yīng)該成功還是失敗扔傅。目前耍共，所有瀏覽器都支持該功能，IE瀏覽器不能低于IE10猎塞。整個CORS通信過程试读，都是瀏覽器自動完成，不需要用戶參與荠耽。對于開發(fā)者來說钩骇，CORS通信與同源的AJAX通信沒有差別，代碼完全一樣。瀏覽器一旦發(fā)現(xiàn)AJAX請求跨源倘屹，就會自動添加一些附加的頭信息银亲，有時還會多出一次附加的請求，但用戶不會有感覺纽匙。

因此务蝠，實現(xiàn)CORS通信的關(guān)鍵是服務(wù)器。只要服務(wù)器實現(xiàn)了CORS接口烛缔，就可以跨源通信馏段。

服務(wù)器端對于CORS的支持，主要就是通過設(shè)置Access-Control-Allow-Origin來進行的践瓷。如果瀏覽器檢測到相應(yīng)的設(shè)置院喜，就可以允許Ajax進行跨域的訪問。更多有關(guān)跨域資源共享 CORS 的知識

瀏覽器中可以查看對應(yīng)的響應(yīng)頭当窗，舉個例子够坐，如下

栗子

服務(wù)端允許CORS，服務(wù)端需要針對接口設(shè)置的一系列響應(yīng)頭 (Response Headers)

該字段必需崖面。設(shè)置允許請求的域名元咙，多個域名以逗號分隔，也可以設(shè)置成 * 即允許所有源訪問
Access-Control-Allow-Origin:  http://www.YOURDOMAIN.com
該字段必需巫员。設(shè)置允許請求的方法庶香，多個方法以逗號分隔
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
該字段可選。設(shè)置允許請求自定義的請求頭字段简识，多個字段以逗號分隔
Access-Control-Allow-Headers: Authorization
該字段可選赶掖。設(shè)置是否允許發(fā)送 Cookies
Access-Control-Allow-Credentials: true                              

瀏覽器將CORS請求分成兩類：簡單請求（simple request）和非簡單請求（not-so-simple request）。

1.簡單請求
目前大多數(shù)情況都采用這種方式七扰。簡單請求只需要設(shè)置Access-Control-Allow-Origin即可奢赂。滿足以下兩個條件，就屬于簡單請求颈走。

• 請求方法是這三種方法之一：HEAD膳灶，GET，POST
• HTTP頭不超出一下幾種字段
  Accept
  Accept-Language
  Content-Language
  Last-Event-ID
  Content-Type：只限于三個值application/x-www-form-urlencoded立由、multipart/form-data轧钓、text/plain

2.非簡單請求
非簡單請求會發(fā)出一次預(yù)檢測請求，返回碼是204锐膜，預(yù)檢測通過才會真正發(fā)出請求毕箍，這才返回200。來看栗子：

204預(yù)檢測

非簡單請求需要根據(jù)不同情況配置不同的響應(yīng)頭道盏，一系列響應(yīng)頭配置項見上方

接口請求之使用代理跨域

這個說法相信不陌生而柑，我們依然使用前端域名請求文捶，然后有一個中介商---代理把這個請求轉(zhuǎn)發(fā)到真正的后端域名上，那也就不存在跨域問題了媒咳。
比較普遍的Nginx拄轻，簡單的配置一下就可以了。了解更多的配置信息：nginx詳解

server{
    # 監(jiān)聽9099端口
    listen 9099;
    # 本地的域名是localhost
    server_name localhost;
    #凡是localhost:9099/api這個樣子的伟葫，都轉(zhuǎn)發(fā)到真正的服務(wù)端地址http://baidu.com
    location ^~ /api {
        proxy_pass http://baidu.com;
    }    
}

然后前端這邊的請求地址是http://localhost:9099/api/xxx,然后Nginx監(jiān)聽到地址是localhost:9099/api的請求恨搓，就幫我們轉(zhuǎn)發(fā)到真正的服務(wù)端地址http://baidu.com

CORS與JSONP的使用目的相同，但是比JSONP更強大筏养。JSONP只支持GET請求斧抱，CORS支持所有類型的HTTP請求。JSONP的優(yōu)勢在于支持老式瀏覽器渐溶，以及在服務(wù)端同意jsonp方式時辉浦，可以向不支持CORS的網(wǎng)站請求數(shù)據(jù)。Nginx可以說是最方便的茎辐，不過需要部署Nginx才行宪郊，需要對服務(wù)器有一定的理解，不太適合剛?cè)腴T的同學(xué)拖陆，當(dāng)然也可以請后臺同學(xué)幫忙部署弛槐。

好像懂了點什么

跨窗口操作DOM之postMessage

window.postMessage(data,origin) 是HTML5的一個接口，專注實現(xiàn)不同窗口不同頁面的跨域通訊依啰。

現(xiàn)在是這么一個情況,由于同源策略的限制下，a.html不能操作iframe(b.html)里面的dom缀棍，那么使用postMessage就可以解決這一情況

<html>
<div>
    <button @click="postMessage">給iframe發(fā)消息</button>
    <iframe id="myIframe" src="b.html"></iframe>
</div>
<script>
var myIframe = document.getElementById('myIframe');
myIframe.contentWindow.postMessage('hello world!', 'b.html');
</script>
</html>

然后b.html頁面通過message事件監(jiān)聽并接受消息:

window.addEventListener('message',function(event) {
    var data = event.data; //消息  
    var origin = event.origin; //消息來源地址  
    var source = event.source; //消息來源的Window對象
    // 為了安全性宅此，一定要對來源做校驗
    if (origin == "a.html") {
        alert(data); //hello world!
        source.postMessage('回信啦', 'a.html'); // a.html頁面也用message方法接收就行
    }
});

跨窗口操作DOM之document.domain

這種方式只適合主域名相同机错，但子域名不同的iframe跨域爬范。
比如主域名是http://baidu.com/:8888，子域名是http://child.baidu.com/:8888弱匪，這種情況下給兩個頁面設(shè)置相同的document.domain即document.domain = baidu.com就可以訪問各自的window對象了青瀑。

參考文章

前端跨域整理
不要再問我跨域的問題了

讀后感

可以愉快的裝逼了