無論是前端同學還是后端同學，可能都接觸過跨域問題，網上已經有了很多介紹跨域問題和解決方案的博客文章，筆者之前也是看過很多關于跨域問題的文章，當時感覺已經了解得差不多了，不過最近又有了一些新的認識，所以寫這篇文章記錄一下，希望也能對讀者有所幫助，當然，本文是筆者自己的認識和實踐，如果有不準確的地方，還請不吝指教，
在正式介紹之前，大家可以先思考一下下面幾個問題：
1、跨域問題是瀏覽器導致的還是服務端導致的？
2、為什么在服務端配置幾個回應頭就可以解決跨域問題？
3、發生跨域問題時，請求發送出去了沒有？服務端有沒有接收到請求，有沒有進行處理和回應？
4、為什么在瀏覽器里發送Ajax請求會發生跨域，但是在瀏覽器地址欄直接請求介面或者通過postman卻不會有問題？
5、跨域問題（或者說背后的同源策略）到底保護的是誰？
這幾個問題是筆者最近重新認識或者是重新確認的問題，本文主要是圍繞上面的幾個問題展開的，對于一些基礎知識（如同源策略等）則不會贅述，還請大家自行百度，
對于問題1，大家應該都知道答案——瀏覽器，具體來說是瀏覽器同源策略的限制，
既然是瀏覽器的限制，那瀏覽器限制的是什么，請求還是回應？最開始筆者也是認為是限制了請求，跨域問題發生的時候，瀏覽器攔截了請求，沒有發送出去，但是這種理解無法解釋問題2，如果請求沒有發送出去，也就是請求根本就沒有到達服務端，服務端的配置又有什么用呢？
實際上，瀏覽器限制的是回應，
這個問題也比較容易驗證，讀者可以在本地啟動一個服務端測驗介面，用來接收前端頁面的請求（設定斷點或者列印日志來確認請求是否接收成功），比如介面地址為：http://localhost:8080/test，然后再寫一個前端頁面，通過 Ajax 方式請求后端介面，需要保證前端頁面的訪問也是通過域名訪問的（比較簡單的方式是使用 python -m SimpleHTTPServer 8000），比如訪問地址是：http://localhost:8000/test.html，最終的結果證明，發生跨域報錯時，請求已經發送出去了，而且服務端接收了請求并且進行了正常的處理，
確認了限制回應這個問題，那么問題2和問題3就迎刃而解了，
對于問題4，其實也容易理解，大家可以回到“同源”和“跨域”這兩個詞本身，對于直接發出的請求，無論是從瀏覽器的地址欄發出的請求，還是 postman 發出的請求，還是 Java 程式發出的請求，根本沒有當前域的概念，實際上每發出一個請求，都是在獨立請求一個資源，而不是在一個網站回傳的頁面里，再去請求另外一個網站/埠的資源，自然也就不會造成跨域了，
對于問題5，其實是要解釋限制回應這種方式，對于服務端來說是沒有保護作用的，要解釋這個問題，還是要回到同源策略，這是瀏覽器的安全策略，雖然也是要保護用戶的資料，但是是從瀏覽器的角度出發的，簡單說是要瀏覽器保證在A域名下謹慎接收B域名回傳的資源，防止B域名回傳的資源是竊取A域名用戶資料的惡意資源，這種保護只是最基礎的保護機制（也可以說是最弱的保護），你不能指望同源策略來完全保護用戶資料，對于用戶資料的保護，主要作業還是在服務端完成，服務端要保證請求是合法的、是已經鑒權的，
以上便是讀者最近關于跨域問題的新認識，
在這里提一下，同源策略是一個非常核心、非常基礎的策略，是 Web 前端安全的核心，網上有人說，
《Web前端黑客技術揭秘》，非常系統的決議了前端安全知識，這些知識都是要圍繞著同源策略展開的，可想而知它是有多重要
對于同源策略的理解，當前也只是停留在大概是什么、大概能解決什么問題的階段，對于理解跨域問題已經基本足夠，但是對于具體的場景還是理解不多，希望日后能有機會再整理一篇關于同源策略的深度文章，可能那時候對于跨域也會有更深的理解，
參考文章：
瀏覽器的同源策略
https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy
瀏覽器同源政策及其規避方法，阮一峰
http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
不要再問我跨域的問題了
https://segmentfault.com/a/1190000015597029
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/231540.html
標籤：其他
上一篇：阿里人的不傳之秘：內部億級架構設計開發筆記（億級架構及優化等等）
下一篇：C++ 浮點數精度判定