不管是前端同窗仍是後端同窗，可能都接觸過跨域問題。網上已經有了不少介紹跨域問題和解決方案的博客文章，筆者以前也是看過不少關於跨域問題的文章，當時感受已經瞭解得差很少了，不過最近又有了一些新的認識，因此寫這篇文章記錄一下，但願也能對讀者有所幫助。固然，本文是筆者本身的認識和實踐，若是有不許確的地方，還請不吝指教。html
在正式介紹以前，你們能夠先思考一下下面幾個問題：前端
一、跨域問題是瀏覽器致使的仍是服務端致使的？python
二、爲何在服務端配置幾個響應頭就能夠解決跨域問題？segmentfault
三、發生跨域問題時，請求發送出去了沒有？服務端有沒有接收到請求，有沒有進行處理和響應？後端
四、爲何在瀏覽器裏發送Ajax請求會發生跨域，可是在瀏覽器地址欄直接請求接口或者經過postman卻不會有問題？跨域
五、跨域問題（或者說背後的同源策略）到底保護的是誰？瀏覽器
這幾個問題是筆者最近從新認識或者是從新確認的問題。本文主要是圍繞上面的幾個問題展開的，對於一些基礎知識（如同源策略等）則不會贅述，還請你們自行百度。安全
對於問題1，你們應該都知道答案——瀏覽器，具體來講是瀏覽器同源策略的限制。post
既然是瀏覽器的限制，那瀏覽器限制的是什麼，請求仍是響應？最開始筆者也是認爲是限制了請求，跨域問題發生的時候，瀏覽器攔截了請求，沒有發送出去。可是這種理解沒法解釋問題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
不要再問我跨域的問題了