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