前后端分離大勢所趨擂仍，跨域問題更是老生常談戴尸，隨便用標題去google或百度一下粥航，能搜出一大片解決方案琅捏，那么為啥又要寫一遍呢，不急往下看递雀。
問題背景：
Same Origin Policy柄延，譯為“同源策略”。它是對于客戶端腳本（尤其是JavaScript）的重要安全度量標準缀程，其目的在于防止某個文檔或者腳本從多個不同“origin”（源）裝載搜吧。
它認為自任何站點裝載的信賴內(nèi)容是不安全的。當被瀏覽器半信半疑的腳本運行在沙箱時杨凑，它們應該只被允許訪問來自同一站點的資源滤奈，而不是那些來自其它站點可能懷有惡意的資源。
注：具有相同的Origin撩满，也即是擁有相同的協(xié)議蜒程、主機地址以及端口绅你。一旦這三項數(shù)據(jù)中有一項不同，那么該資源就將被認為是從不同的Origin得來的昭躺，進而不被允許訪問忌锯。
”
CORS就是為了解決SOP問題而生的，當然CORS不是唯一的解決方案领炫，不過這里不贅述其他解決辦法了汉规。
CORS簡介:
CORS是一個W3C標準，全稱是"跨域資源共享”（Cross-origin resource sharing）驹吮。它允許瀏覽器向跨源(協(xié)議 + 域名 + 端口)服務器，發(fā)出XMLHttpRequest請求晶伦，從而克服了AJAX只能同源使用的限制碟狞。CORS需要瀏覽器和服務器同時支持。它的通信過程婚陪，都是瀏覽器自動完成族沃，不需要用戶參與。
對于開發(fā)者來說泌参，CORS通信與同源的AJAX/Fetch通信沒有差別脆淹，代碼完全一樣。瀏覽器一旦發(fā)現(xiàn)請求跨源沽一，就會自動添加一些附加的頭信息盖溺，有時還會多出一次附加的請求，但用戶不會有感覺铣缠。因此烘嘱，實現(xiàn)CORS通信的關鍵是服務器。只要服務器實現(xiàn)了CORS接口蝗蛙，就可以跨源通信蝇庭。
瀏覽器將CORS請求分成兩類：簡單請求（simple request）和非簡單請求（not-so-simple request）。
瀏覽器發(fā)出CORS簡單請求捡硅，只需要在頭信息之中增加一個Origin字段哮内。
瀏覽器發(fā)出CORS非簡單請求，會在正式通信之前壮韭，增加一次OPTIONS查詢請求北发，稱為"預檢"請求（preflight）。瀏覽器先詢問服務器泰涂，當前網(wǎng)頁所在的域名是否在服務器的許可名單之中鲫竞，以及可以使用哪些HTTP動詞和頭信息字段。只有得到肯定答復逼蒙，瀏覽器才會發(fā)出正式的XMLHttpRequest請求从绘，否則就報錯。
簡單請求就是HEAD、GET僵井、POST請求陕截，并且HTTP的頭信息不超出以下幾種字段 Accept、Accept-Language批什、Content-Language农曲、Last-Event-ID、Content-Type 注：Content-Type：只限于三個值application/x-www-form-urlencoded驻债、multipart/form-data乳规、text/plain
反之，就是非簡單請求合呐。
其實實現(xiàn)CORS很簡單暮的，就是在服務端加一些響應頭，并且這樣做對前端來說是無感知的淌实，很方便冻辩。
詳解響應頭：
Access-Control-Allow-Origin 該字段必填。它的值要么是請求時Origin字段的具體值拆祈，要么是一個*恨闪，表示接受任意域名的請求。
Access-Control-Allow-Methods 該字段必填放坏。它的值是逗號分隔的一個具體的字符串或者*咙咽，表明服務器支持的所有跨域請求的方法。注意轻姿，返回的是所有支持的方法犁珠，而不單是瀏覽器請求的那個方法。這是為了避免多次"預檢"請求互亮。
Access-Control-Expose-Headers 該字段可選犁享。CORS請求時，XMLHttpRequest對象的getResponseHeader()方法只能拿到6個基本字段：Cache-Control豹休、Content-Language炊昆、Content-Type、Expires威根、Last-Modified凤巨、Pragma。如果想拿到其他字段洛搀，就必須在Access-Control-Expose-Headers里面指定敢茁。
Access-Control-Allow-Credentials 該字段可選。它的值是一個布爾值留美，表示是否允許發(fā)送Cookie.默認情況下彰檬，不發(fā)生Cookie伸刃，即：false。對服務器有特殊要求的請求逢倍，比如請求方法是PUT或DELETE捧颅，或者Content-Type字段的類型是application/json昔案，這個值只能設為true英支。如果服務器不要瀏覽器發(fā)送Cookie，刪除該字段即可鸵熟。
Access-Control-Max-Age 該字段可選亮蒋，用來指定本次預檢請求的有效期扣典，單位為秒。在有效期間慎玖，不用發(fā)出另一條預檢請求激捏。
順便提一下，如果在開發(fā)中凄吏，發(fā)現(xiàn)每次發(fā)起請求都是兩條，一次OPTIONS闰蛔，一次正常請求痕钢，注意是每次，那么就需要配置Access-Control-Max-Age序六，避免每次都發(fā)出預檢請求任连。
解決辦法：
解決辦法有三種：
第一種辦法:
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
@Configuration
public class CorsConfig implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOrigins("*")
.allowedMethods("GET", "HEAD", "POST", "PUT", "DELETE", "OPTIONS")
.allowCredentials(true)
.maxAge(3600)
.allowedHeaders("*");
}
}
這種方式是全局配置的，網(wǎng)上也大都是這種解決辦法例诀，但是很多都是基于舊的spring版本随抠，比如：
https://blog.csdn.net/tiangongkaiwu152368/article/details/81099169
”
文中WebMvcConfigurerAdapter在spring5.0已經(jīng)被標記為Deprecated，點開源碼可以看到：
/**
* An implementation of {@link WebMvcConfigurer} with empty methods allowing
* subclasses to override only the methods they're interested in.
*
* @author Rossen Stoyanchev
* @since 3.1
* @deprecated as of 5.0 {@link WebMvcConfigurer} has default methods (made
* possible by a Java 8 baseline) and can be implemented directly without the
* need for this adapter
*/
@Deprecated
public abstract class WebMvcConfigurerAdapter implements WebMvcConfigurer {}
像這種過時的類或者方法繁涂，spring的作者們一定會在注解上面說明原因拱她，并告訴你新的該用哪個，這是非常優(yōu)秀的編碼習慣扔罪，點贊秉沼！
spring5最低支持到jdk1.8，所以注釋中明確表明矿酵，你可以直接實現(xiàn)WebMvcConfigurer接口唬复，無需再用這個適配器，因為jdk1.8支持接口中存在default-method全肮。
第二種辦法:
import org.springframework.context.annotation.Configuration;
import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
@WebFilter(filterName = "CorsFilter ")
@Configuration
public class CorsFilter implements Filter {
@Override
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
HttpServletResponse response = (HttpServletResponse) res;
response.setHeader("Access-Control-Allow-Origin","*");
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Allow-Methods", "POST, GET, PATCH, DELETE, PUT");
response.setHeader("Access-Control-Max-Age", "3600");
response.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
chain.doFilter(req, res);
}
}
這種辦法敞咧，是基于過濾器的方式，方式簡單明了辜腺，就是在response中寫入這些響應頭休建，好多文章都是第一種和第二種方式都叫你配置乍恐，其實這是沒有必要的，只需要一種即可丰包。
這里也吐槽一下禁熏，大家不求甚解的精神。
第三種辦法：
public class GoodsController {
@CrossOrigin(origins = "http://localhost:4000")
@GetMapping("goods-url")
public Response queryGoodsWithGoodsUrl(@RequestParam String goodsUrl) throws Exception {}
}
沒錯就是@CrossOrigin注解邑彪，點開注解
@Target({ ElementType.METHOD, ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface CrossOrigin {}
從元注解@Target可以看出瞧毙，注解可以放在method、class等上面寄症，類似RequestMapping宙彪，也就是說，整個controller下面的方法可以都受控制有巧，也可以單個方法受控制释漆。
也可以得知，這個是最小粒度的cors控制辦法了篮迎，精確到單個請求級別男图。
以上三種方法都可以解決問題，最常用的應該是第一種甜橱、第二種逊笆，控制在自家?guī)讉€域名范圍下足以，一般沒必要搞得太細岂傲。
這三種配置方式都用了的話难裆，誰生效呢，類似css中樣式镊掖，就近原則乃戈，懂了吧。
所以在開發(fā)新項目時亩进，不需要等聯(lián)調(diào)時候症虑，讓前端來找你了，我早就解決了跨域問題归薛。
