調(diào))
1. 跨域問題到底是怎么出現(xiàn)的先直接說結(jié)論調(diào)用后端接口報(bào)跨域不是你代碼寫得不對(duì)而是瀏覽器出于安全策略主動(dòng)攔截了響應(yīng)。后端接口本身可能返回了正常數(shù)據(jù)但瀏覽器拿到之后發(fā)現(xiàn)“這個(gè)響應(yīng)和我當(dāng)前頁面不在同一個(gè)源”直接丟掉了然后在控制臺(tái)給你拋一個(gè)紅色的報(bào)錯(cuò)。這是Web開發(fā)里最容易讓人血壓升高的報(bào)錯(cuò)之一尤其是前后端分離的項(xiàng)目第一次聯(lián)調(diào)接口的時(shí)候十有八九會(huì)撞上。要理解跨域先得知道瀏覽器的“同源策略”。所謂同源指的是協(xié)議Protocol、域名Host、端口Port三者完全一致。只要有一個(gè)不一樣瀏覽器就會(huì)判定為跨域。舉個(gè)例子你的前端頁面跑在http://localhost:8080后端接口跑在http://localhost:9090端口不一樣這就跨域了。更別說前端在https://admin.example.com后端在https://api.example.com域名不一樣同樣跨域。很多人第一次遇到這個(gè)問題時(shí)會(huì)覺得莫名其妙明明用Postman調(diào)接口返回?cái)?shù)據(jù)很正常怎么放到頁面上就報(bào)跨域原因就在于Postman這類HTTP客戶端沒有實(shí)現(xiàn)同源策略它發(fā)請求、接響應(yīng)都是原原本本的而瀏覽器會(huì)多做一個(gè)“安全檢查”。這個(gè)安全檢查不是針對(duì)請求本身關(guān)鍵是針對(duì)響應(yīng)。也就是說請求可能已經(jīng)發(fā)出去了后端也可能處理了但瀏覽器不讓頁面拿到返回的數(shù)據(jù)。這種機(jī)制的初衷是保護(hù)用戶如果沒有同源策略你在A網(wǎng)站打開的頁面就可以隨意請求B網(wǎng)站的接口讀取B網(wǎng)站的登錄態(tài)和數(shù)據(jù)那整個(gè)互聯(lián)網(wǎng)的賬號(hào)體系就全亂套了。理解這一層之后你再看跨域解決方案思路就清晰了——所有方案的本質(zhì)都是想辦法讓瀏覽器認(rèn)為這個(gè)響應(yīng)是“安全”的。在實(shí)際開發(fā)環(huán)境里最常見的情況就是前后端分離。前端工程用Vite或Webpack起一個(gè)本地開發(fā)服務(wù)器后端是獨(dú)立的Spring Boot或者Nginx代理的網(wǎng)關(guān)服務(wù)兩邊端口不同、域名不同跨域幾乎是必然發(fā)生的。生產(chǎn)環(huán)境雖然通常會(huì)通過Nginx做反向代理把接口和頁面收斂到同一個(gè)域名下但開發(fā)階段、以及接口被第三方系統(tǒng)直接調(diào)用的場景跨域還是繞不開。所以這個(gè)問題不是偶發(fā)的小毛病而是前后端開發(fā)者必須掌握的基礎(chǔ)功。2. 主流的跨域解決方案選型網(wǎng)上關(guān)于跨域解決方案的文章很多但大多數(shù)只講了怎么配置沒講為什么選這個(gè)方案。我先把主流的方案列一個(gè)對(duì)比表然后針對(duì)不同的項(xiàng)目場景說明怎么選。方案實(shí)現(xiàn)位置是否需要后端配合支持請求類型典型場景CORS跨域資源共享后端加響應(yīng)頭必須所有HTTP方法前后端分離、對(duì)外開放APINginx反向代理網(wǎng)關(guān)層配置不需要改代碼所有HTTP方法生產(chǎn)環(huán)境收斂域名開發(fā)代理Vite/Webpack proxy前端開發(fā)服務(wù)器不需要所有HTTP方法本地聯(lián)調(diào)JSONP前端動(dòng)態(tài)script標(biāo)簽必須僅GET老系統(tǒng)兼容、第三方接口WebSocket協(xié)議天然不受同源限制不需要特殊處理雙向通信實(shí)時(shí)消息推送Fiddler代理轉(zhuǎn)發(fā)本地調(diào)試工具不需要改代碼所有HTTP方法調(diào)試第三方接口、驗(yàn)證響應(yīng)頭這幾種方案里CORS是目前最正規(guī)、最通用的做法也是后端開發(fā)者最常被問到的問題。它的核心思想是瀏覽器發(fā)請求時(shí)帶上Origin頭表示當(dāng)前頁面來源后端在響應(yīng)里通過Access-Control-Allow-Origin這個(gè)響應(yīng)頭告訴瀏覽器“這個(gè)來源的頁面可以拿我的數(shù)據(jù)”。瀏覽器拿到響應(yīng)頭一看哦允許的那就放行。就這么簡單。Nginx反向代理則是一項(xiàng)繞過機(jī)制因?yàn)橥床呗允菫g覽器限制的所以如果前端頁面和接口在瀏覽器看來是同一個(gè)域名那就根本不存在跨域。做法是讓Nginx監(jiān)聽某個(gè)獨(dú)立域名比如https://api.example.com然后把所有進(jìn)入這個(gè)域名的請求轉(zhuǎn)發(fā)到真正的后端服務(wù)上。對(duì)外暴露的是統(tǒng)一的域名后端細(xì)節(jié)全被隱藏了。開發(fā)代理的原理和Nginx相似但只存在于本地開發(fā)環(huán)境。Vite、Webpack這類開發(fā)服務(wù)器內(nèi)置了代理功能你請求/api開頭的路徑開發(fā)服務(wù)器會(huì)幫你轉(zhuǎn)發(fā)到目標(biāo)后端地址瀏覽器的視角里請求始終只發(fā)給了當(dāng)前站點(diǎn)跨域自然不成立。JSONP是個(gè)老古董了它的原理是用script標(biāo)簽加載外部資源不受同源策略限制的特性把接口數(shù)據(jù)塞進(jìn)一個(gè)JavaScript回調(diào)函數(shù)里返回。但這個(gè)方案只能支持GET請求而且有安全隱患新項(xiàng)目我基本不推薦。除非是接第三方老系統(tǒng)的數(shù)據(jù)人家只提供JSONP接口那沒辦法。Fiddler代理配置跨域這個(gè)方案有點(diǎn)特殊它屬于“前端自己搞定”的一招。你本地裝一個(gè)Fiddler設(shè)置一個(gè)代理轉(zhuǎn)發(fā)規(guī)則把請求先打到本地再由Fiddler轉(zhuǎn)發(fā)到目標(biāo)后端并且在后端響應(yīng)里追加CORS響應(yīng)頭。適合用來聯(lián)調(diào)那種不允許你改代碼的第三方接口或者后端同事暫時(shí)還沒加上CORS響應(yīng)頭時(shí)臨時(shí)救急用。整體選型建議如下開發(fā)階段優(yōu)先用Vite/Webpack代理不依賴后端任何改動(dòng)生產(chǎn)環(huán)境用Nginx反向代理收斂域名接口要對(duì)第三方系統(tǒng)開放時(shí)老老實(shí)實(shí)讓后端加CORS響應(yīng)頭。前兩個(gè)是“繞”第三個(gè)是“允許”繞是開發(fā)效率的權(quán)宜之計(jì)允許才是對(duì)外服務(wù)的正牌方案。3. 后端接口加CORS響應(yīng)頭的完整實(shí)操后端加CORS響應(yīng)頭是最直接、最底層的解法。不管你用的什么語言、什么框架核心就是添加幾個(gè)HTTP響應(yīng)頭。我先把標(biāo)準(zhǔn)響應(yīng)頭講清楚再給出不同框架的具體配置方式。3.1 CORS響應(yīng)頭參數(shù)拆解后端接口要放行跨域請求至少需要設(shè)置以下響應(yīng)頭響應(yīng)頭作用示例值A(chǔ)ccess-Control-Allow-Origin允許哪個(gè)來源訪問https://admin.example.com或*Access-Control-Allow-Methods允許哪些HTTP方法GET, POST, PUT, DELETE, OPTIONSAccess-Control-Allow-Headers允許請求攜帶哪些自定義頭Content-Type, Authorization, X-Requested-WithAccess-Control-Allow-Credentials是否允許攜帶CookietrueAccess-Control-Max-Age預(yù)檢請求結(jié)果的緩存時(shí)間3600第一個(gè)響應(yīng)頭是最核心的幾乎決定了整個(gè)配置的對(duì)錯(cuò)。如果后端只寫一個(gè)Access-Control-Allow-Origin: *意思是任意來源都能訪問這個(gè)配置在接口完全是公開數(shù)據(jù)時(shí)可以用。但它在兩種情況下會(huì)翻車一種是你需要攜帶Cookie。瀏覽器規(guī)定如果請求需要攜帶憑證CookieAccess-Control-Allow-Origin不能是*必須明確寫成具體的來源域名同時(shí)Access-Control-Allow-Credentials必須設(shè)為true。用通配符時(shí)瀏覽器檢查到Allow-Credentials: true和Allow-Origin: *同時(shí)存在會(huì)直接判定為非法配置拒絕放行。另一種是你需要區(qū)分不同環(huán)境的來源。比如說測試環(huán)境前端跑在http://test.example.com生產(chǎn)環(huán)境跑在https://admin.example.com如果后端寫死一個(gè)來源那另一個(gè)環(huán)境又失靈了。這就要么在后端配置里做成動(dòng)態(tài)讀取請求的Origin頭要么維護(hù)一個(gè)白名單列表。再強(qiáng)調(diào)一下Access-Control-Allow-Headers。前端發(fā)請求時(shí)如果帶了諸如Authorization用來做登錄態(tài)鑒權(quán)、Content-Type: application/json這類請求頭瀏覽器在預(yù)檢階段就會(huì)問后端“我能不能帶這些頭”如果后端返回的Allow-Headers里沒有包含對(duì)應(yīng)的頭瀏覽器一樣攔截。很多項(xiàng)目配置了Allow-Origin和Allow-Methods但漏了Authorization結(jié)果前端明明帶了token請求接口還是報(bào)跨域。這個(gè)坑我在聯(lián)調(diào)時(shí)踩了好幾次。3.2 預(yù)檢請求OPTIONS必須處理跨域分兩種情況簡單請求和預(yù)檢請求。簡單請求是GET、POSTContent-Type限定為普通表單格式這類不會(huì)觸發(fā)預(yù)檢的請求。瀏覽器直接發(fā)送請求后端響應(yīng)里帶上CORS頭就算完事。但一旦請求帶了自定義頭、或者Content-Type是application/json、或者用了PUT/DELETE方法瀏覽器會(huì)在正式請求之前先發(fā)一個(gè)OPTIONS請求來“探路”這就是預(yù)檢請求。許多后端項(xiàng)目用Spring Security或者自定義攔截器默認(rèn)攔下了OPTIONS請求結(jié)果預(yù)檢返回403前端正式請求根本不存在發(fā)出去。報(bào)錯(cuò)信息往往是“CORS preflight response did not return HTTP status 200”之類的方向完全不對(duì)。正確的做法有兩種一種是讓OPTIONS請求直接放行不經(jīng)過登錄鑒權(quán)另一種是單獨(dú)寫一個(gè)攔截器只要請求方法是OPTIONS就直接返回200并且附帶CORS響應(yīng)頭。不管用什么框架都要確保預(yù)檢請求能拿到正確的CORS頭這一步到位了主請求才會(huì)放行。3.3 各主流后端框架的配置方式拿Java的Spring Boot舉例最省事的方式是寫一個(gè)配置類實(shí)現(xiàn)WebMvcConfigurer接口重寫addCorsMappings方法Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }這里有個(gè)細(xì)節(jié)allowCredentials(true)時(shí)方法名是allowedOriginPatterns而不是allowedOrigins。因?yàn)閍llowedOrigins(*)在SpringBoot 2.4之后的版本里和allowCredentials(true)會(huì)沖突直接用allowedOriginPatterns(*)更省心。如果項(xiàng)目里用了Spring Security光配置WebMvcConfigurer可能不夠因?yàn)镾pring Security的過濾器鏈執(zhí)行順序在MVC之前CORS頭會(huì)被安全過濾器先攔掉。需要在Security配置里也加上CORS支持http.cors().and()然后在安全規(guī)則里對(duì)OPTIONS請求放行authorizeRequests() .antMatchers(HttpMethod.OPTIONS, /**).permitAll() .anyRequest().authenticated()Node.js的Express服務(wù)用cors中間件幾行就搞定const cors require(cors); app.use(cors({ origin: [https://admin.example.com, http://localhost:8080], methods: [GET, POST, PUT, DELETE], allowedHeaders: [Content-Type, Authorization], credentials: true, maxAge: 3600 }));如果你不想引中間件也可以在請求處理的最前面手工設(shè)置響應(yīng)頭原理是一模一樣的。PHP后端設(shè)置響應(yīng)頭的方式比較直接在入口文件或者每個(gè)接口的公共邏輯里加上header(Access-Control-Allow-Origin: *); header(Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS); header(Access-Control-Allow-Headers: Content-Type, Authorization); if ($_SERVER[REQUEST_METHOD] OPTIONS) { http_response_code(200); exit(); }后面這個(gè)OPTIONS判斷很重要。PHP項(xiàng)目很多老代碼沒有分層接口各自為戰(zhàn)如果不在公共入口統(tǒng)一處理預(yù)檢請求每個(gè)接口的跨域配置就會(huì)寫得很分散排查起來非常痛苦。建議所有PHP項(xiàng)目把CORS配置抽到入口文件比如index.php或者公共中間層統(tǒng)一管理。3.4 網(wǎng)關(guān)層統(tǒng)一處理CORS才是長遠(yuǎn)之計(jì)如果你負(fù)責(zé)的項(xiàng)目是微服務(wù)架構(gòu)或者后端有多個(gè)服務(wù)每個(gè)服務(wù)各配一套CORS響應(yīng)頭是個(gè)災(zāi)難。比如說你有用戶服務(wù)、訂單服務(wù)、支付服務(wù)前端一次請求可能要調(diào)動(dòng)其中兩三個(gè)如果各自配置不統(tǒng)一排查的時(shí)候一會(huì)兒好的、一會(huì)兒壞的非常難追。這種情況下建議在網(wǎng)關(guān)層統(tǒng)一處理。以Nginx為例在location級(jí)別加上CORS配置即可add_header Access-Control-Allow-Origin $http_origin; add_header Access-Control-Allow-Methods GET, POST, PUT, DELETE, OPTIONS; add_header Access-Control-Allow-Headers Content-Type, Authorization, X-Requested-With; add_header Access-Control-Allow-Credentials true; add_header Access-Control-Max-Age 3600; if ($request_method OPTIONS) { return 204; }這里用$http_origin而不是寫死具體域名是為了動(dòng)態(tài)回顯請求來源方便后續(xù)擴(kuò)展多個(gè)域名來源。但注意如果后端接口涉及重要數(shù)據(jù)配合Nginx的map指令做一個(gè)域名白名單校驗(yàn)更穩(wěn)。比如固定只允許admin.example.com和app.example.com兩個(gè)來源其他的一律拒絕。在網(wǎng)關(guān)層解決CORS還有個(gè)額外好處各個(gè)后端服務(wù)代碼里完全不用關(guān)心跨域配置邏輯更干凈這也是我對(duì)接多服務(wù)項(xiàng)目時(shí)最喜歡的方式。但要注意Nginx的add_header在PostAction階段只在200和204等部分狀態(tài)碼上生效對(duì)于4xx、5xx錯(cuò)誤響應(yīng)默認(rèn)不會(huì)帶上CORS頭如果需要錯(cuò)誤響應(yīng)也能被前端讀取得用always參數(shù)add_header Access-Control-Allow-Origin $http_origin always;。這個(gè)細(xì)節(jié)容易被忽略前端拿到的錯(cuò)誤信息往往是“Blocked by CORS policy”實(shí)際上后端已經(jīng)返回了500但響應(yīng)頭里沒有CORS頭瀏覽器連錯(cuò)誤詳情都不給你看。4. 前端處理跨域的實(shí)操方案后端接口能在代碼里改那怎么都好說。但很多時(shí)候你是在聯(lián)調(diào)階段或者其他團(tuán)隊(duì)的系統(tǒng)后端代碼改不動(dòng)或者改起來要排期這時(shí)候前端就得自己想辦法繞過去。4.1 Vite和Webpack代理配置本地開發(fā)階段我?guī)缀鯚o腦推薦用腳手架自帶的代理功能。Vite項(xiàng)目的配置在vite.config.js里export default defineConfig({ server: { proxy: { /api: { target: http://localhost:9090, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ) } } } })這段配置的意思是頁面里所有以/api開頭的請求Vite開發(fā)服務(wù)器把它轉(zhuǎn)發(fā)到http://localhost:9090。changeOrigin: true的作用是把請求頭里的Host字段改成目標(biāo)地址避免后端有些業(yè)務(wù)邏輯通過Host來校驗(yàn)來源。rewrite那一步是把路徑中的/api前綴去掉再轉(zhuǎn)發(fā)給后端這取決于后端接口到底帶不帶/api前綴。如果后端接口本身就是/api/user/list這種帶前綴的那就不用rewrite如果后端接口是/user/list而前端約定統(tǒng)一加/api前綴方便代理識(shí)別就一定要rewrite。這個(gè)細(xì)節(jié)很容易栽跟頭配置之后接口404多半就是這個(gè)原因。Webpack項(xiàng)目的配置邏輯完全一樣位置在webpack.config.js的devServer.proxydevServer: { proxy: { /api: { target: http://localhost:9090, changeOrigin: true, pathRewrite: { ^/api: } } } }用了代理之后前端代碼里請求地址不要寫全路徑http://localhost:9090/user/list而是寫相對(duì)路徑/api/user/list。這樣開發(fā)環(huán)境走代理生產(chǎn)環(huán)境拆掉代理邏輯或者換Nginx轉(zhuǎn)發(fā)代碼基本不用動(dòng)。4.2 Fiddler代理配置跨域的實(shí)操細(xì)節(jié)Fiddler本質(zhì)是個(gè)HTTP調(diào)試代理平時(shí)大家用它抓包看請求響應(yīng)但它也能做請求轉(zhuǎn)發(fā)——這就為“前端臨時(shí)突破跨域”提供了一個(gè)思路。場景是這樣的后端接口已經(jīng)部署在測試環(huán)境但測試環(huán)境接口沒有配CORS響應(yīng)頭你本地頁面直接請求它必跨域。這時(shí)候Fiddler可以幫你做一個(gè)“響應(yīng)頭附加器”請求照常發(fā)到后端Fiddler在收到響應(yīng)后往響應(yīng)頭里附加Access-Control-Allow-Origin: *這樣瀏覽器認(rèn)為自己收到了合法的跨域響應(yīng)就不再攔截。在Fiddler里先開啟代理監(jiān)聽菜單欄選擇Tools - Options - Connections勾選Allow remote computers to connect記住默認(rèn)代理端口是8888。然后把瀏覽器的代理設(shè)置為127.0.0.1:8888Chrome可以用SwitchyOmega擴(kuò)展快速切換或者直接用--proxy-server127.0.0.1:8888啟動(dòng)參數(shù)。接下來在Fiddler的OnBeforeResponse腳本里添加一段邏輯在響應(yīng)頭里注入CORS字段。打開FiddlerScript Editor找到OnBeforeResponse函數(shù)里面對(duì)所有Content-Type以json開頭的響應(yīng)添加響應(yīng)頭if (oSession.ResponseHeader.Exists(Access-Control-Allow-Origin)) { oSession.ResponseHeader.Remove(Access-Control-Allow-Origin); } oSession.ResponseHeader.Add(Access-Control-Allow-Origin, *);保存之后Fiddler會(huì)根據(jù)腳本重寫每次響應(yīng)的CORS頭瀏覽器就再也不報(bào)跨域了。這個(gè)做法的優(yōu)點(diǎn)是完全不依賴后端配合適用于聯(lián)調(diào)階段。缺點(diǎn)也很明顯Fiddler是個(gè)桌面工具只能在你本地用不能幫到團(tuán)隊(duì)其他人而且全局代理會(huì)影響所有網(wǎng)絡(luò)請求調(diào)試其他項(xiàng)目的時(shí)候可能會(huì)有干擾。另外Fiddler修改的是本地調(diào)試代理上的響應(yīng)應(yīng)用在生產(chǎn)環(huán)境是不現(xiàn)實(shí)的——生產(chǎn)環(huán)境還是得靠真正的Nginx或CORS配置。所以我的定位是臨時(shí)救急可以長期方案別這么做。4.3 JSONP在什么情況下值得用JSONP是零幾年就出現(xiàn)的老方案到現(xiàn)在基本只活躍在老舊系統(tǒng)里了。它的實(shí)現(xiàn)思路是利用script標(biāo)簽加載資源不受同源策略限制這一點(diǎn)讓后端返回一段JavaScript代碼把數(shù)據(jù)包在回調(diào)函數(shù)里。前端代碼如下function handleResponse(data) { console.log(data); } const script document.createElement(script); script.src http://api.example.com/geo/get?callbackhandleResponse; document.body.appendChild(script);后端識(shí)別到回調(diào)參數(shù)callbackhandleResponse之后返回的內(nèi)容不是普通JSON而是handleResponse({name: 張三, id: 123})瀏覽器加載這個(gè)腳本等于執(zhí)行了一個(gè)函數(shù)調(diào)用數(shù)據(jù)就進(jìn)入前端的回調(diào)函數(shù)了。但在2024年的今天我不建議任何新項(xiàng)目主動(dòng)選JSONP。首先它只支持GET想POST數(shù)據(jù)很難看其次它要求后端配合改造接口返回格式后端把數(shù)據(jù)拼進(jìn)JS代碼里安全隱患和調(diào)試難度都上升再加上現(xiàn)代瀏覽器對(duì)JSONP的跨域限制雖然沒有取消但各大站點(diǎn)已經(jīng)逐步禁用基于頂層導(dǎo)航的第三方腳本行為這種方案越來越不好使了。那什么時(shí)候值得用我遇到的真實(shí)場景是對(duì)接一個(gè)老舊的第三方支付平臺(tái)對(duì)方只提供JSONP接口查詢訂單狀態(tài)改接口得走版控流程。這種時(shí)候捏著鼻子也得用JSONP但用的時(shí)候要做好安全性剝離開的預(yù)期——任何用JSONP返回的數(shù)據(jù)都不要直接拼進(jìn)DOM里防止XSS注入。5. 排查跨域問題的思路與常見坑跨域報(bào)錯(cuò)是前端最容易碰到、也最容易踩坑的一類問題。報(bào)錯(cuò)信息五花八門有說No Access-Control-Allow-Origin header is present的有說Response to preflight request doesnt pass access control check的還有說Credential is not supported if the CORS header Access-Control-Allow-Origin is *的。5.1 一套標(biāo)準(zhǔn)的排查思路碰到跨域報(bào)錯(cuò)先別慌按照這個(gè)順序查第一步確認(rèn)改動(dòng)邊界。問一下自己這個(gè)問題是我最近改動(dòng)代碼才出現(xiàn)的還是首次聯(lián)調(diào)就遇到如果是首次聯(lián)調(diào)多半是后端壓根沒配CORS響應(yīng)頭或者代理配置路徑不對(duì)。如果是改代碼后突然出現(xiàn)多半是后端某個(gè)響應(yīng)頭被改動(dòng)了或者請求從簡單請求變成了預(yù)檢請求比如新增了自定義請求頭。第二步打開DevTools的Network面板看請求到底發(fā)出去了沒有以及響應(yīng)是什么狀態(tài)。如果請求顯示為(cors blocked)說明請求連預(yù)檢都沒通過如果請求有響應(yīng)但內(nèi)容是紅色報(bào)錯(cuò)說明請求發(fā)出去了但瀏覽器不允許讀取。這是兩個(gè)完全不同的方向前者重點(diǎn)查后端是否處理OPTIONS后者重點(diǎn)查響應(yīng)頭是否完整。第三步在Network里點(diǎn)開那個(gè)被攔截的請求看兩個(gè)東西請求頭里的Origin是什么響應(yīng)頭里有沒有Access-Control-Allow-Origin。如果響應(yīng)頭完全沒有CORS字段后端配置缺失直接找后端如果響應(yīng)頭里有CORS字段但和Origin不匹配是白名單配置不對(duì)也找后端如果請求壓根在Network里沒出現(xiàn)那就是前端代理配置沒生效或者路徑不對(duì)。第四步確認(rèn)是不是Cookie引發(fā)的沖突。如果后端配置了Access-Control-Allow-Origin: *同時(shí)前端請求又設(shè)置了withCredentials: true瀏覽器會(huì)直接拒絕。原因前面講過允許攜帶憑證時(shí)來源必須是具體域名不能用通配符?？吹綀?bào)錯(cuò)信息里有credential字樣就往這個(gè)方向查。5.2 常見問題速查表報(bào)錯(cuò)現(xiàn)象可能性原因排查方向No Access-Control-Allow-Origin header is present后端完全沒配置CORS頭后端加響應(yīng)頭CORS preflight did not succeedOPTIONS請求被攔截或返回非2xx放行OPTIONS請求Credential is not supported if the CORS header is *Allow-Origin寫死*且Allow-Credentials為true改為具體域名來源Request header field authorization is not allowedAllow-Headers沒包含Authorization后端加Authorization前端代理配置后接口404路徑rewrite規(guī)則寫錯(cuò)檢查/api前綴是否被正確替換代理后接口頻繁斷連changeOrigin未設(shè)true或代理目標(biāo)地址不穩(wěn)定檢查目標(biāo)域名是否加了http://協(xié)議用了Nginx轉(zhuǎn)發(fā)還是報(bào)跨域add_header缺always參數(shù)錯(cuò)誤響應(yīng)沒帶CORS頭加always5.3 幾個(gè)我用經(jīng)驗(yàn)換來的提醒第一Access-Control-Allow-Origin: *和Access-Control-Allow-Credentials: true最好別同時(shí)用。就算某些情況下后端能配置出來瀏覽器也可能因?yàn)榘姹静煌憩F(xiàn)得飄忽不定。如果接口需要攜帶登錄態(tài)Cookie建議后端維護(hù)一個(gè)可信來源域名列表配置成精確域名。第二生產(chǎn)環(huán)境的跨域問題幾乎別讓代碼改來解決。正確的順序是先看Nginx層能不能通過add_header來解決再考慮后端代碼加CORS頭最后才考慮前端改代理。原因無他線上環(huán)境不可能為了調(diào)試而去刷新瀏覽器緩存、改代碼配置靠網(wǎng)關(guān)層統(tǒng)一收斂是最可控的。第三開發(fā)環(huán)境用代理解決跨域時(shí)一定要確認(rèn)代理配置是否真的生效。我見過很多開發(fā)者改了vite.config.js后只刷新頁面沒重啟DevServer代理配置完全不生效白折騰了半小時(shí)。Vite的代理配置改動(dòng)是需要重啟服務(wù)才能生效的這是官方文檔都寫了但很少有人注意到的地方。第四調(diào)試跨域問題不要用Postman來判斷“接口到底通不通”。Postman壓根不執(zhí)行瀏覽器同源策略接口通不通和瀏覽器能不能訪問是兩碼事。我用過最舒服的調(diào)試方式就是直接看瀏覽器DevTools的Network面板接口請求和響應(yīng)在那里展示得一清二楚比任何外部工具體驗(yàn)都好。6. 一次跨域問題的完整排查實(shí)錄分享一個(gè)真實(shí)的案例。前陣子幫一個(gè)電商后臺(tái)項(xiàng)目做權(quán)限模塊的聯(lián)調(diào)前端工程跑在http://localhost:3000后端服務(wù)跑在http://192.168.31.85:8080中間沒有Nginx純開發(fā)環(huán)境聯(lián)調(diào)。前端同學(xué)說調(diào)用登錄接口報(bào)跨域控制臺(tái)報(bào)錯(cuò)信息是Access to XMLHttpRequest at http://192.168.31.85:8080/api/login from origin http://localhost:3000 has been blocked by CORS policy。我第一反應(yīng)是后端沒配置CORS。打開后端代碼一看登錄接口所在的Controller確實(shí)沒加任何CORS相關(guān)注解不過鑒權(quán)過濾器里倒是有個(gè)統(tǒng)一的跨域處理邏輯但那個(gè)過濾器只對(duì)帶有效token的接口生效登錄接口走的是匿名認(rèn)證鏈壓根沒經(jīng)過過濾器。這個(gè)坑很有意思其他業(yè)務(wù)接口都有token過濾器會(huì)附加CORS頭所以聯(lián)調(diào)時(shí)發(fā)現(xiàn)其他接口都能通就登錄接口跨域。前端同學(xué)一度以為是登錄接口代碼的問題還去核對(duì)了好半天請求參數(shù)格式完全跑偏。解決辦法是在后端的Spring Security配置里增加一個(gè)獨(dú)立的CORS配置源處理/api/login、/api/refresh-token這類匿名接口的OPTIONS預(yù)檢和CORS頭。這個(gè)案例很好地說明了一個(gè)道理跨域配置放在攔截器、過濾器的層級(jí)里時(shí)一定要確認(rèn)不同請求路徑、不同認(rèn)證狀態(tài)下的覆蓋范圍是否一致否則就是出現(xiàn)了“部分接口通部分接口不通”的詭異現(xiàn)象。后來又排查了一個(gè)更隱蔽的問題前端某個(gè)請求報(bào)跨域但Network面板里能看到響應(yīng)頭包含完整的CORS字段。后來仔細(xì)一看發(fā)現(xiàn)后端配置了Access-Control-Allow-Origin: *但前端發(fā)送前設(shè)置了withCredentials: true因?yàn)橛行┙涌谛枰獛ookie做狀態(tài)同步瀏覽器直接否決了。后端同事把Allow-Origin改成精確來源之后問題才消停。這兩個(gè)案例讓我更加確定跨域排查時(shí)最忌諱的是只盯著一行報(bào)錯(cuò)信息就下結(jié)論。報(bào)錯(cuò)信息只是瀏覽器給出的最終判斷它背后的因果關(guān)系可能要沿著“請求頭→響應(yīng)頭→攔截器/過濾器→全局配置”這條鏈路一層層剝開才能找到。最后給大家一個(gè)我常用的實(shí)操習(xí)慣在項(xiàng)目初期就讓后端在Nginx層統(tǒng)一把CORS響應(yīng)頭配好前端開發(fā)環(huán)境用Vite代理生產(chǎn)環(huán)境走Nginx轉(zhuǎn)發(fā)全部收口成一種方式。這樣前后端各管一段接口聯(lián)調(diào)時(shí)幾乎沒有多余的跨域噪音。如果你已經(jīng)有一個(gè)線上項(xiàng)目在跑而且之前一直沒管過跨域那建議先在網(wǎng)關(guān)層把CORS頭加上這是改動(dòng)成本最低、收益最大的操作。改完之后再用DevTools刷新頁面驗(yàn)證幾個(gè)關(guān)鍵接口只要返回頭帶上了Access-Control-Allow-Origin整個(gè)流程就順了。 跨域解決方案精要：CORS、Nginx代理與前后端聯(lián)調(diào)
1. 跨域問題到底是怎么出現(xiàn)的先直接說結(jié)論調(diào)用后端接口報(bào)跨域不是你代碼寫得不對(duì)而是瀏覽器出于安全策略主動(dòng)攔截了響應(yīng)。后端接口本身可能返回了正常數(shù)據(jù)但瀏覽器拿到之后發(fā)現(xiàn)“這個(gè)響應(yīng)和我當(dāng)前頁面不在同一個(gè)源”直接丟掉了然后在控制臺(tái)給你拋一個(gè)紅色的報(bào)錯(cuò)。這是Web開發(fā)里最容易讓人血壓升高的報(bào)錯(cuò)之一尤其是前后端分離的項(xiàng)目第一次聯(lián)調(diào)接口的時(shí)候十有八九會(huì)撞上。要理解跨域先得知道瀏覽器的“同源策略”。所謂同源指的是協(xié)議Protocol、域名Host、端口Port三者完全一致。只要有一個(gè)不一樣瀏覽器就會(huì)判定為跨域。舉個(gè)例子你的前端頁面跑在http://localhost:8080后端接口跑在http://localhost:9090端口不一樣這就跨域了。更別說前端在https://admin.example.com后端在https://api.example.com域名不一樣同樣跨域。很多人第一次遇到這個(gè)問題時(shí)會(huì)覺得莫名其妙明明用Postman調(diào)接口返回?cái)?shù)據(jù)很正常怎么放到頁面上就報(bào)跨域原因就在于Postman這類HTTP客戶端沒有實(shí)現(xiàn)同源策略它發(fā)請求、接響應(yīng)都是原原本本的而瀏覽器會(huì)多做一個(gè)“安全檢查”。這個(gè)安全檢查不是針對(duì)請求本身關(guān)鍵是針對(duì)響應(yīng)。也就是說請求可能已經(jīng)發(fā)出去了后端也可能處理了但瀏覽器不讓頁面拿到返回的數(shù)據(jù)。這種機(jī)制的初衷是保護(hù)用戶如果沒有同源策略你在A網(wǎng)站打開的頁面就可以隨意請求B網(wǎng)站的接口讀取B網(wǎng)站的登錄態(tài)和數(shù)據(jù)那整個(gè)互聯(lián)網(wǎng)的賬號(hào)體系就全亂套了。理解這一層之后你再看跨域解決方案思路就清晰了——所有方案的本質(zhì)都是想辦法讓瀏覽器認(rèn)為這個(gè)響應(yīng)是“安全”的。在實(shí)際開發(fā)環(huán)境里最常見的情況就是前后端分離。前端工程用Vite或Webpack起一個(gè)本地開發(fā)服務(wù)器后端是獨(dú)立的Spring Boot或者Nginx代理的網(wǎng)關(guān)服務(wù)兩邊端口不同、域名不同跨域幾乎是必然發(fā)生的。生產(chǎn)環(huán)境雖然通常會(huì)通過Nginx做反向代理把接口和頁面收斂到同一個(gè)域名下但開發(fā)階段、以及接口被第三方系統(tǒng)直接調(diào)用的場景跨域還是繞不開。所以這個(gè)問題不是偶發(fā)的小毛病而是前后端開發(fā)者必須掌握的基礎(chǔ)功。2. 主流的跨域解決方案選型網(wǎng)上關(guān)于跨域解決方案的文章很多但大多數(shù)只講了怎么配置沒講為什么選這個(gè)方案。我先把主流的方案列一個(gè)對(duì)比表然后針對(duì)不同的項(xiàng)目場景說明怎么選。方案實(shí)現(xiàn)位置是否需要后端配合支持請求類型典型場景CORS跨域資源共享后端加響應(yīng)頭必須所有HTTP方法前后端分離、對(duì)外開放APINginx反向代理網(wǎng)關(guān)層配置不需要改代碼所有HTTP方法生產(chǎn)環(huán)境收斂域名開發(fā)代理Vite/Webpack proxy前端開發(fā)服務(wù)器不需要所有HTTP方法本地聯(lián)調(diào)JSONP前端動(dòng)態(tài)script標(biāo)簽必須僅GET老系統(tǒng)兼容、第三方接口WebSocket協(xié)議天然不受同源限制不需要特殊處理雙向通信實(shí)時(shí)消息推送Fiddler代理轉(zhuǎn)發(fā)本地調(diào)試工具不需要改代碼所有HTTP方法調(diào)試第三方接口、驗(yàn)證響應(yīng)頭這幾種方案里CORS是目前最正規(guī)、最通用的做法也是后端開發(fā)者最常被問到的問題。它的核心思想是瀏覽器發(fā)請求時(shí)帶上Origin頭表示當(dāng)前頁面來源后端在響應(yīng)里通過Access-Control-Allow-Origin這個(gè)響應(yīng)頭告訴瀏覽器“這個(gè)來源的頁面可以拿我的數(shù)據(jù)”。瀏覽器拿到響應(yīng)頭一看哦允許的那就放行。就這么簡單。Nginx反向代理則是一項(xiàng)繞過機(jī)制因?yàn)橥床呗允菫g覽器限制的所以如果前端頁面和接口在瀏覽器看來是同一個(gè)域名那就根本不存在跨域。做法是讓Nginx監(jiān)聽某個(gè)獨(dú)立域名比如https://api.example.com然后把所有進(jìn)入這個(gè)域名的請求轉(zhuǎn)發(fā)到真正的后端服務(wù)上。對(duì)外暴露的是統(tǒng)一的域名后端細(xì)節(jié)全被隱藏了。開發(fā)代理的原理和Nginx相似但只存在于本地開發(fā)環(huán)境。Vite、Webpack這類開發(fā)服務(wù)器內(nèi)置了代理功能你請求/api開頭的路徑開發(fā)服務(wù)器會(huì)幫你轉(zhuǎn)發(fā)到目標(biāo)后端地址瀏覽器的視角里請求始終只發(fā)給了當(dāng)前站點(diǎn)跨域自然不成立。JSONP是個(gè)老古董了它的原理是用script標(biāo)簽加載外部資源不受同源策略限制的特性把接口數(shù)據(jù)塞進(jìn)一個(gè)JavaScript回調(diào)函數(shù)里返回。但這個(gè)方案只能支持GET請求而且有安全隱患新項(xiàng)目我基本不推薦。除非是接第三方老系統(tǒng)的數(shù)據(jù)人家只提供JSONP接口那沒辦法。Fiddler代理配置跨域這個(gè)方案有點(diǎn)特殊它屬于“前端自己搞定”的一招。你本地裝一個(gè)Fiddler設(shè)置一個(gè)代理轉(zhuǎn)發(fā)規(guī)則把請求先打到本地再由Fiddler轉(zhuǎn)發(fā)到目標(biāo)后端并且在后端響應(yīng)里追加CORS響應(yīng)頭。適合用來聯(lián)調(diào)那種不允許你改代碼的第三方接口或者后端同事暫時(shí)還沒加上CORS響應(yīng)頭時(shí)臨時(shí)救急用。整體選型建議如下開發(fā)階段優(yōu)先用Vite/Webpack代理不依賴后端任何改動(dòng)生產(chǎn)環(huán)境用Nginx反向代理收斂域名接口要對(duì)第三方系統(tǒng)開放時(shí)老老實(shí)實(shí)讓后端加CORS響應(yīng)頭。前兩個(gè)是“繞”第三個(gè)是“允許”繞是開發(fā)效率的權(quán)宜之計(jì)允許才是對(duì)外服務(wù)的正牌方案。3. 后端接口加CORS響應(yīng)頭的完整實(shí)操后端加CORS響應(yīng)頭是最直接、最底層的解法。不管你用的什么語言、什么框架核心就是添加幾個(gè)HTTP響應(yīng)頭。我先把標(biāo)準(zhǔn)響應(yīng)頭講清楚再給出不同框架的具體配置方式。3.1 CORS響應(yīng)頭參數(shù)拆解后端接口要放行跨域請求至少需要設(shè)置以下響應(yīng)頭響應(yīng)頭作用示例值A(chǔ)ccess-Control-Allow-Origin允許哪個(gè)來源訪問https://admin.example.com或*Access-Control-Allow-Methods允許哪些HTTP方法GET, POST, PUT, DELETE, OPTIONSAccess-Control-Allow-Headers允許請求攜帶哪些自定義頭Content-Type, Authorization, X-Requested-WithAccess-Control-Allow-Credentials是否允許攜帶CookietrueAccess-Control-Max-Age預(yù)檢請求結(jié)果的緩存時(shí)間3600第一個(gè)響應(yīng)頭是最核心的幾乎決定了整個(gè)配置的對(duì)錯(cuò)。如果后端只寫一個(gè)Access-Control-Allow-Origin: *意思是任意來源都能訪問這個(gè)配置在接口完全是公開數(shù)據(jù)時(shí)可以用。但它在兩種情況下會(huì)翻車一種是你需要攜帶Cookie。瀏覽器規(guī)定如果請求需要攜帶憑證CookieAccess-Control-Allow-Origin不能是*必須明確寫成具體的來源域名同時(shí)Access-Control-Allow-Credentials必須設(shè)為true。用通配符時(shí)瀏覽器檢查到Allow-Credentials: true和Allow-Origin: *同時(shí)存在會(huì)直接判定為非法配置拒絕放行。另一種是你需要區(qū)分不同環(huán)境的來源。比如說測試環(huán)境前端跑在http://test.example.com生產(chǎn)環(huán)境跑在https://admin.example.com如果后端寫死一個(gè)來源那另一個(gè)環(huán)境又失靈了。這就要么在后端配置里做成動(dòng)態(tài)讀取請求的Origin頭要么維護(hù)一個(gè)白名單列表。再強(qiáng)調(diào)一下Access-Control-Allow-Headers。前端發(fā)請求時(shí)如果帶了諸如Authorization用來做登錄態(tài)鑒權(quán)、Content-Type: application/json這類請求頭瀏覽器在預(yù)檢階段就會(huì)問后端“我能不能帶這些頭”如果后端返回的Allow-Headers里沒有包含對(duì)應(yīng)的頭瀏覽器一樣攔截。很多項(xiàng)目配置了Allow-Origin和Allow-Methods但漏了Authorization結(jié)果前端明明帶了token請求接口還是報(bào)跨域。這個(gè)坑我在聯(lián)調(diào)時(shí)踩了好幾次。3.2 預(yù)檢請求OPTIONS必須處理跨域分兩種情況簡單請求和預(yù)檢請求。簡單請求是GET、POSTContent-Type限定為普通表單格式這類不會(huì)觸發(fā)預(yù)檢的請求。瀏覽器直接發(fā)送請求后端響應(yīng)里帶上CORS頭就算完事。但一旦請求帶了自定義頭、或者Content-Type是application/json、或者用了PUT/DELETE方法瀏覽器會(huì)在正式請求之前先發(fā)一個(gè)OPTIONS請求來“探路”這就是預(yù)檢請求。許多后端項(xiàng)目用Spring Security或者自定義攔截器默認(rèn)攔下了OPTIONS請求結(jié)果預(yù)檢返回403前端正式請求根本不存在發(fā)出去。報(bào)錯(cuò)信息往往是“CORS preflight response did not return HTTP status 200”之類的方向完全不對(duì)。正確的做法有兩種一種是讓OPTIONS請求直接放行不經(jīng)過登錄鑒權(quán)另一種是單獨(dú)寫一個(gè)攔截器只要請求方法是OPTIONS就直接返回200并且附帶CORS響應(yīng)頭。不管用什么框架都要確保預(yù)檢請求能拿到正確的CORS頭這一步到位了主請求才會(huì)放行。3.3 各主流后端框架的配置方式拿Java的Spring Boot舉例最省事的方式是寫一個(gè)配置類實(shí)現(xiàn)WebMvcConfigurer接口重寫addCorsMappings方法Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }這里有個(gè)細(xì)節(jié)allowCredentials(true)時(shí)方法名是allowedOriginPatterns而不是allowedOrigins。因?yàn)閍llowedOrigins(*)在SpringBoot 2.4之后的版本里和allowCredentials(true)會(huì)沖突直接用allowedOriginPatterns(*)更省心。如果項(xiàng)目里用了Spring Security光配置WebMvcConfigurer可能不夠因?yàn)镾pring Security的過濾器鏈執(zhí)行順序在MVC之前CORS頭會(huì)被安全過濾器先攔掉。需要在Security配置里也加上CORS支持http.cors().and()然后在安全規(guī)則里對(duì)OPTIONS請求放行authorizeRequests() .antMatchers(HttpMethod.OPTIONS, /**).permitAll() .anyRequest().authenticated()Node.js的Express服務(wù)用cors中間件幾行就搞定const cors require(cors); app.use(cors({ origin: [https://admin.example.com, http://localhost:8080], methods: [GET, POST, PUT, DELETE], allowedHeaders: [Content-Type, Authorization], credentials: true, maxAge: 3600 }));如果你不想引中間件也可以在請求處理的最前面手工設(shè)置響應(yīng)頭原理是一模一樣的。PHP后端設(shè)置響應(yīng)頭的方式比較直接在入口文件或者每個(gè)接口的公共邏輯里加上header(Access-Control-Allow-Origin: *); header(Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS); header(Access-Control-Allow-Headers: Content-Type, Authorization); if ($_SERVER[REQUEST_METHOD] OPTIONS) { http_response_code(200); exit(); }后面這個(gè)OPTIONS判斷很重要。PHP項(xiàng)目很多老代碼沒有分層接口各自為戰(zhàn)如果不在公共入口統(tǒng)一處理預(yù)檢請求每個(gè)接口的跨域配置就會(huì)寫得很分散排查起來非常痛苦。建議所有PHP項(xiàng)目把CORS配置抽到入口文件比如index.php或者公共中間層統(tǒng)一管理。3.4 網(wǎng)關(guān)層統(tǒng)一處理CORS才是長遠(yuǎn)之計(jì)如果你負(fù)責(zé)的項(xiàng)目是微服務(wù)架構(gòu)或者后端有多個(gè)服務(wù)每個(gè)服務(wù)各配一套CORS響應(yīng)頭是個(gè)災(zāi)難。比如說你有用戶服務(wù)、訂單服務(wù)、支付服務(wù)前端一次請求可能要調(diào)動(dòng)其中兩三個(gè)如果各自配置不統(tǒng)一排查的時(shí)候一會(huì)兒好的、一會(huì)兒壞的非常難追。這種情況下建議在網(wǎng)關(guān)層統(tǒng)一處理。以Nginx為例在location級(jí)別加上CORS配置即可add_header Access-Control-Allow-Origin $http_origin; add_header Access-Control-Allow-Methods GET, POST, PUT, DELETE, OPTIONS; add_header Access-Control-Allow-Headers Content-Type, Authorization, X-Requested-With; add_header Access-Control-Allow-Credentials true; add_header Access-Control-Max-Age 3600; if ($request_method OPTIONS) { return 204; }這里用$http_origin而不是寫死具體域名是為了動(dòng)態(tài)回顯請求來源方便后續(xù)擴(kuò)展多個(gè)域名來源。但注意如果后端接口涉及重要數(shù)據(jù)配合Nginx的map指令做一個(gè)域名白名單校驗(yàn)更穩(wěn)。比如固定只允許admin.example.com和app.example.com兩個(gè)來源其他的一律拒絕。在網(wǎng)關(guān)層解決CORS還有個(gè)額外好處各個(gè)后端服務(wù)代碼里完全不用關(guān)心跨域配置邏輯更干凈這也是我對(duì)接多服務(wù)項(xiàng)目時(shí)最喜歡的方式。但要注意Nginx的add_header在PostAction階段只在200和204等部分狀態(tài)碼上生效對(duì)于4xx、5xx錯(cuò)誤響應(yīng)默認(rèn)不會(huì)帶上CORS頭如果需要錯(cuò)誤響應(yīng)也能被前端讀取得用always參數(shù)add_header Access-Control-Allow-Origin $http_origin always;。這個(gè)細(xì)節(jié)容易被忽略前端拿到的錯(cuò)誤信息往往是“Blocked by CORS policy”實(shí)際上后端已經(jīng)返回了500但響應(yīng)頭里沒有CORS頭瀏覽器連錯(cuò)誤詳情都不給你看。4. 前端處理跨域的實(shí)操方案后端接口能在代碼里改那怎么都好說。但很多時(shí)候你是在聯(lián)調(diào)階段或者其他團(tuán)隊(duì)的系統(tǒng)后端代碼改不動(dòng)或者改起來要排期這時(shí)候前端就得自己想辦法繞過去。4.1 Vite和Webpack代理配置本地開發(fā)階段我?guī)缀鯚o腦推薦用腳手架自帶的代理功能。Vite項(xiàng)目的配置在vite.config.js里export default defineConfig({ server: { proxy: { /api: { target: http://localhost:9090, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ) } } } })這段配置的意思是頁面里所有以/api開頭的請求Vite開發(fā)服務(wù)器把它轉(zhuǎn)發(fā)到http://localhost:9090。changeOrigin: true的作用是把請求頭里的Host字段改成目標(biāo)地址避免后端有些業(yè)務(wù)邏輯通過Host來校驗(yàn)來源。rewrite那一步是把路徑中的/api前綴去掉再轉(zhuǎn)發(fā)給后端這取決于后端接口到底帶不帶/api前綴。如果后端接口本身就是/api/user/list這種帶前綴的那就不用rewrite如果后端接口是/user/list而前端約定統(tǒng)一加/api前綴方便代理識(shí)別就一定要rewrite。這個(gè)細(xì)節(jié)很容易栽跟頭配置之后接口404多半就是這個(gè)原因。Webpack項(xiàng)目的配置邏輯完全一樣位置在webpack.config.js的devServer.proxydevServer: { proxy: { /api: { target: http://localhost:9090, changeOrigin: true, pathRewrite: { ^/api: } } } }用了代理之后前端代碼里請求地址不要寫全路徑http://localhost:9090/user/list而是寫相對(duì)路徑/api/user/list。這樣開發(fā)環(huán)境走代理生產(chǎn)環(huán)境拆掉代理邏輯或者換Nginx轉(zhuǎn)發(fā)代碼基本不用動(dòng)。4.2 Fiddler代理配置跨域的實(shí)操細(xì)節(jié)Fiddler本質(zhì)是個(gè)HTTP調(diào)試代理平時(shí)大家用它抓包看請求響應(yīng)但它也能做請求轉(zhuǎn)發(fā)——這就為“前端臨時(shí)突破跨域”提供了一個(gè)思路。場景是這樣的后端接口已經(jīng)部署在測試環(huán)境但測試環(huán)境接口沒有配CORS響應(yīng)頭你本地頁面直接請求它必跨域。這時(shí)候Fiddler可以幫你做一個(gè)“響應(yīng)頭附加器”請求照常發(fā)到后端Fiddler在收到響應(yīng)后往響應(yīng)頭里附加Access-Control-Allow-Origin: *這樣瀏覽器認(rèn)為自己收到了合法的跨域響應(yīng)就不再攔截。在Fiddler里先開啟代理監(jiān)聽菜單欄選擇Tools - Options - Connections勾選Allow remote computers to connect記住默認(rèn)代理端口是8888。然后把瀏覽器的代理設(shè)置為127.0.0.1:8888Chrome可以用SwitchyOmega擴(kuò)展快速切換或者直接用--proxy-server127.0.0.1:8888啟動(dòng)參數(shù)。接下來在Fiddler的OnBeforeResponse腳本里添加一段邏輯在響應(yīng)頭里注入CORS字段。打開FiddlerScript Editor找到OnBeforeResponse函數(shù)里面對(duì)所有Content-Type以json開頭的響應(yīng)添加響應(yīng)頭if (oSession.ResponseHeader.Exists(Access-Control-Allow-Origin)) { oSession.ResponseHeader.Remove(Access-Control-Allow-Origin); } oSession.ResponseHeader.Add(Access-Control-Allow-Origin, *);保存之后Fiddler會(huì)根據(jù)腳本重寫每次響應(yīng)的CORS頭瀏覽器就再也不報(bào)跨域了。這個(gè)做法的優(yōu)點(diǎn)是完全不依賴后端配合適用于聯(lián)調(diào)階段。缺點(diǎn)也很明顯Fiddler是個(gè)桌面工具只能在你本地用不能幫到團(tuán)隊(duì)其他人而且全局代理會(huì)影響所有網(wǎng)絡(luò)請求調(diào)試其他項(xiàng)目的時(shí)候可能會(huì)有干擾。另外Fiddler修改的是本地調(diào)試代理上的響應(yīng)應(yīng)用在生產(chǎn)環(huán)境是不現(xiàn)實(shí)的——生產(chǎn)環(huán)境還是得靠真正的Nginx或CORS配置。所以我的定位是臨時(shí)救急可以長期方案別這么做。4.3 JSONP在什么情況下值得用JSONP是零幾年就出現(xiàn)的老方案到現(xiàn)在基本只活躍在老舊系統(tǒng)里了。它的實(shí)現(xiàn)思路是利用script標(biāo)簽加載資源不受同源策略限制這一點(diǎn)讓后端返回一段JavaScript代碼把數(shù)據(jù)包在回調(diào)函數(shù)里。前端代碼如下function handleResponse(data) { console.log(data); } const script document.createElement(script); script.src http://api.example.com/geo/get?callbackhandleResponse; document.body.appendChild(script);后端識(shí)別到回調(diào)參數(shù)callbackhandleResponse之后返回的內(nèi)容不是普通JSON而是handleResponse({name: 張三, id: 123})瀏覽器加載這個(gè)腳本等于執(zhí)行了一個(gè)函數(shù)調(diào)用數(shù)據(jù)就進(jìn)入前端的回調(diào)函數(shù)了。但在2024年的今天我不建議任何新項(xiàng)目主動(dòng)選JSONP。首先它只支持GET想POST數(shù)據(jù)很難看其次它要求后端配合改造接口返回格式后端把數(shù)據(jù)拼進(jìn)JS代碼里安全隱患和調(diào)試難度都上升再加上現(xiàn)代瀏覽器對(duì)JSONP的跨域限制雖然沒有取消但各大站點(diǎn)已經(jīng)逐步禁用基于頂層導(dǎo)航的第三方腳本行為這種方案越來越不好使了。那什么時(shí)候值得用我遇到的真實(shí)場景是對(duì)接一個(gè)老舊的第三方支付平臺(tái)對(duì)方只提供JSONP接口查詢訂單狀態(tài)改接口得走版控流程。這種時(shí)候捏著鼻子也得用JSONP但用的時(shí)候要做好安全性剝離開的預(yù)期——任何用JSONP返回的數(shù)據(jù)都不要直接拼進(jìn)DOM里防止XSS注入。5. 排查跨域問題的思路與常見坑跨域報(bào)錯(cuò)是前端最容易碰到、也最容易踩坑的一類問題。報(bào)錯(cuò)信息五花八門有說No Access-Control-Allow-Origin header is present的有說Response to preflight request doesnt pass access control check的還有說Credential is not supported if the CORS header Access-Control-Allow-Origin is *的。5.1 一套標(biāo)準(zhǔn)的排查思路碰到跨域報(bào)錯(cuò)先別慌按照這個(gè)順序查第一步確認(rèn)改動(dòng)邊界。問一下自己這個(gè)問題是我最近改動(dòng)代碼才出現(xiàn)的還是首次聯(lián)調(diào)就遇到如果是首次聯(lián)調(diào)多半是后端壓根沒配CORS響應(yīng)頭或者代理配置路徑不對(duì)。如果是改代碼后突然出現(xiàn)多半是后端某個(gè)響應(yīng)頭被改動(dòng)了或者請求從簡單請求變成了預(yù)檢請求比如新增了自定義請求頭。第二步打開DevTools的Network面板看請求到底發(fā)出去了沒有以及響應(yīng)是什么狀態(tài)。如果請求顯示為(cors blocked)說明請求連預(yù)檢都沒通過如果請求有響應(yīng)但內(nèi)容是紅色報(bào)錯(cuò)說明請求發(fā)出去了但瀏覽器不允許讀取。這是兩個(gè)完全不同的方向前者重點(diǎn)查后端是否處理OPTIONS后者重點(diǎn)查響應(yīng)頭是否完整。第三步在Network里點(diǎn)開那個(gè)被攔截的請求看兩個(gè)東西請求頭里的Origin是什么響應(yīng)頭里有沒有Access-Control-Allow-Origin。如果響應(yīng)頭完全沒有CORS字段后端配置缺失直接找后端如果響應(yīng)頭里有CORS字段但和Origin不匹配是白名單配置不對(duì)也找后端如果請求壓根在Network里沒出現(xiàn)那就是前端代理配置沒生效或者路徑不對(duì)。第四步確認(rèn)是不是Cookie引發(fā)的沖突。如果后端配置了Access-Control-Allow-Origin: *同時(shí)前端請求又設(shè)置了withCredentials: true瀏覽器會(huì)直接拒絕。原因前面講過允許攜帶憑證時(shí)來源必須是具體域名不能用通配符?？吹綀?bào)錯(cuò)信息里有credential字樣就往這個(gè)方向查。5.2 常見問題速查表報(bào)錯(cuò)現(xiàn)象可能性原因排查方向No Access-Control-Allow-Origin header is present后端完全沒配置CORS頭后端加響應(yīng)頭CORS preflight did not succeedOPTIONS請求被攔截或返回非2xx放行OPTIONS請求Credential is not supported if the CORS header is *Allow-Origin寫死*且Allow-Credentials為true改為具體域名來源Request header field authorization is not allowedAllow-Headers沒包含Authorization后端加Authorization前端代理配置后接口404路徑rewrite規(guī)則寫錯(cuò)檢查/api前綴是否被正確替換代理后接口頻繁斷連changeOrigin未設(shè)true或代理目標(biāo)地址不穩(wěn)定檢查目標(biāo)域名是否加了http://協(xié)議用了Nginx轉(zhuǎn)發(fā)還是報(bào)跨域add_header缺always參數(shù)錯(cuò)誤響應(yīng)沒帶CORS頭加always5.3 幾個(gè)我用經(jīng)驗(yàn)換來的提醒第一Access-Control-Allow-Origin: *和Access-Control-Allow-Credentials: true最好別同時(shí)用。就算某些情況下后端能配置出來瀏覽器也可能因?yàn)榘姹静煌憩F(xiàn)得飄忽不定。如果接口需要攜帶登錄態(tài)Cookie建議后端維護(hù)一個(gè)可信來源域名列表配置成精確域名。第二生產(chǎn)環(huán)境的跨域問題幾乎別讓代碼改來解決。正確的順序是先看Nginx層能不能通過add_header來解決再考慮后端代碼加CORS頭最后才考慮前端改代理。原因無他線上環(huán)境不可能為了調(diào)試而去刷新瀏覽器緩存、改代碼配置靠網(wǎng)關(guān)層統(tǒng)一收斂是最可控的。第三開發(fā)環(huán)境用代理解決跨域時(shí)一定要確認(rèn)代理配置是否真的生效。我見過很多開發(fā)者改了vite.config.js后只刷新頁面沒重啟DevServer代理配置完全不生效白折騰了半小時(shí)。Vite的代理配置改動(dòng)是需要重啟服務(wù)才能生效的這是官方文檔都寫了但很少有人注意到的地方。第四調(diào)試跨域問題不要用Postman來判斷“接口到底通不通”。Postman壓根不執(zhí)行瀏覽器同源策略接口通不通和瀏覽器能不能訪問是兩碼事。我用過最舒服的調(diào)試方式就是直接看瀏覽器DevTools的Network面板接口請求和響應(yīng)在那里展示得一清二楚比任何外部工具體驗(yàn)都好。6. 一次跨域問題的完整排查實(shí)錄分享一個(gè)真實(shí)的案例。前陣子幫一個(gè)電商后臺(tái)項(xiàng)目做權(quán)限模塊的聯(lián)調(diào)前端工程跑在http://localhost:3000后端服務(wù)跑在http://192.168.31.85:8080中間沒有Nginx純開發(fā)環(huán)境聯(lián)調(diào)。前端同學(xué)說調(diào)用登錄接口報(bào)跨域控制臺(tái)報(bào)錯(cuò)信息是Access to XMLHttpRequest at http://192.168.31.85:8080/api/login from origin http://localhost:3000 has been blocked by CORS policy。我第一反應(yīng)是后端沒配置CORS。打開后端代碼一看登錄接口所在的Controller確實(shí)沒加任何CORS相關(guān)注解不過鑒權(quán)過濾器里倒是有個(gè)統(tǒng)一的跨域處理邏輯但那個(gè)過濾器只對(duì)帶有效token的接口生效登錄接口走的是匿名認(rèn)證鏈壓根沒經(jīng)過過濾器。這個(gè)坑很有意思其他業(yè)務(wù)接口都有token過濾器會(huì)附加CORS頭所以聯(lián)調(diào)時(shí)發(fā)現(xiàn)其他接口都能通就登錄接口跨域。前端同學(xué)一度以為是登錄接口代碼的問題還去核對(duì)了好半天請求參數(shù)格式完全跑偏。解決辦法是在后端的Spring Security配置里增加一個(gè)獨(dú)立的CORS配置源處理/api/login、/api/refresh-token這類匿名接口的OPTIONS預(yù)檢和CORS頭。這個(gè)案例很好地說明了一個(gè)道理跨域配置放在攔截器、過濾器的層級(jí)里時(shí)一定要確認(rèn)不同請求路徑、不同認(rèn)證狀態(tài)下的覆蓋范圍是否一致否則就是出現(xiàn)了“部分接口通部分接口不通”的詭異現(xiàn)象。后來又排查了一個(gè)更隱蔽的問題前端某個(gè)請求報(bào)跨域但Network面板里能看到響應(yīng)頭包含完整的CORS字段。后來仔細(xì)一看發(fā)現(xiàn)后端配置了Access-Control-Allow-Origin: *但前端發(fā)送前設(shè)置了withCredentials: true因?yàn)橛行┙涌谛枰獛ookie做狀態(tài)同步瀏覽器直接否決了。后端同事把Allow-Origin改成精確來源之后問題才消停。這兩個(gè)案例讓我更加確定跨域排查時(shí)最忌諱的是只盯著一行報(bào)錯(cuò)信息就下結(jié)論。報(bào)錯(cuò)信息只是瀏覽器給出的最終判斷它背后的因果關(guān)系可能要沿著“請求頭→響應(yīng)頭→攔截器/過濾器→全局配置”這條鏈路一層層剝開才能找到。最后給大家一個(gè)我常用的實(shí)操習(xí)慣在項(xiàng)目初期就讓后端在Nginx層統(tǒng)一把CORS響應(yīng)頭配好前端開發(fā)環(huán)境用Vite代理生產(chǎn)環(huán)境走Nginx轉(zhuǎn)發(fā)全部收口成一種方式。這樣前后端各管一段接口聯(lián)調(diào)時(shí)幾乎沒有多余的跨域噪音。如果你已經(jīng)有一個(gè)線上項(xiàng)目在跑而且之前一直沒管過跨域那建議先在網(wǎng)關(guān)層把CORS頭加上這是改動(dòng)成本最低、收益最大的操作。改完之后再用DevTools刷新頁面驗(yàn)證幾個(gè)關(guān)鍵接口只要返回頭帶上了Access-Control-Allow-Origin整個(gè)流程就順了。