1.什么是跨域?
跨域來源於JavaScript的"同源策略"，即只有 協議+主機名+端口號 (如存在)相同，則允許相互訪問。也就是說JavaScript只能訪問和操作自己域下的資源，不能訪問和操作其他域下的資源。跨域問題是 針對JS和ajax的，html本身沒有跨域問題。
查看瀏覽器開發者工具Console報錯：
Failed to load http://a.a.com:8080/A/FromServlet?userName=123: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://b.b.com:8080' is therefore not allowed access.
http://www.abc.com/a/b 調用 http://www.abc.com/d/c（非跨域）
http://www.abc.com/a/b 調用 http://www.def.com/a/b （跨域：域名不一致）
http://www.abc.com:8080/a/b 調用 http://www.abc.com:8081/d/c （跨域：端口不一致）
http://www.abc.com/a/b 調用 https://www.abc.com/d/c （跨域：協議不同）
請注意：localhost和127.0.0.1雖然都指向本機，但也屬於跨域。
2.如何解決跨域？
(1).響應頭添加Header允許訪問
(2).jsonp 只支持get請求不支持post請求
(3).httpClient內部轉發
(4).使用接口網關——nginx、springcloud zuul (互聯網公司常規解決方案)
3.解決方案
解決方式1：響應頭添加Header允許訪問
跨域資源共享（CORS）Cross-Origin Resource Sharing
解決方式2：jsonp 只支持get請求不支持post請求
用法：①dataType改為jsonp ②jsonp : "jsonpCallback"————發送到后端實際為http://a.a.com/a/FromServlet?userName=644064&jsonpCallback=jQueryxxx ③后端獲取get請求中的 jsonpCallback ④構造回調結構
解決方式3：httpClient內部轉發
實現原理很簡單，若想在B站點中通過Ajax訪問A站點獲取結果，固然有ajax跨域問題，但在B站點中訪問B站點獲取結果，不存在跨域問題，這種方式實際上是在B站點中ajax請求訪問B站點的HttpClient，再通過HttpClient轉發請求獲取A站點的數據結果。但這種方式產生了兩次請求，效率低，但內部請求，抓包工具無法分析，安全。
解決方式4：使用nginx搭建企業級接口網關方式
www.a.a.com不能直接請求www.b.b.com的內容，可以通過nginx，根據同域名，但項目名不同進行區分。什么意思呢？這么說可能有點抽象。假設我們公司域名叫www.nginxtest.com
當我們需要訪問www.a.a.com通過www.nginxtest.com/A訪問，並通過nginx轉發到www.a.a.com
當我們需要訪問www.b.b.com通過www.nginxtest.com/B訪問，並通過nginx轉發到www.a.a.com
我們訪問公司的域名時，是"同源"的，只是項目名不同，此時項目名的作用只是為了區分，方便轉發。如果你還不理解的話，先看看我是怎么進行配置的：
我們訪問公司的域名時，是"同源"的，只是項目名不同，此時項目名的作用只是為了區分，方便轉發。如果你還不理解的話，先看看我是怎么進行配置的：
我們訪問以www.nginxtest.com開頭且端口為80的網址，nginx將會進行攔截匹配，若項目名為A，則分發到a.a.com:81。實際上就是通過"同源"的域名，不同的項目名進行區分，通過nginx攔截匹配， 轉發到對應的網址。整個過程，兩次請求，第一次請求nginx服務器，第二次nginx服務器通過攔截匹配分發到對應的網址。
解決方式5：使用Spring Cloud zuul接口網關
雲環境中每個服務自己有跨域解決方案，而網關需要做最外層的跨域解決方案.如果服務已有跨域配置網關也有，會出現*多次配置問題。
使用ZUUL配置忽略頭部信息
跨域配置
