1. 項(xiàng)目概述為什么我們需要跨域共享Cookie在Web開發(fā)中Cookie是維持用戶狀態(tài)、實(shí)現(xiàn)會(huì)話管理的關(guān)鍵技術(shù)。然而當(dāng)你的前端應(yīng)用部署在app.example.com而后端API服務(wù)跑在api.example.com時(shí)一個(gè)棘手的問題就出現(xiàn)了瀏覽器基于同源策略默認(rèn)會(huì)阻止app.example.com的頁面向api.example.com發(fā)送攜帶認(rèn)證Cookie的請(qǐng)求。這就是典型的“跨域”場景。用戶登錄狀態(tài)無法傳遞頁面功能直接癱瘓這絕不是危言聳聽而是每個(gè)前后端分離架構(gòu)的開發(fā)者都必須邁過的一道坎。最近在處理一個(gè)微服務(wù)項(xiàng)目時(shí)我就被這個(gè)問題卡了半天。前端調(diào)用認(rèn)證接口一切正常但后續(xù)的業(yè)務(wù)請(qǐng)求總是返回401未授權(quán)。排查后發(fā)現(xiàn)登錄成功后頒發(fā)的Cookie被瀏覽器“扣留”了沒有隨跨域請(qǐng)求發(fā)送出去。這促使我系統(tǒng)地梳理和對(duì)比了實(shí)現(xiàn)Cookie跨域共享的主流方案。簡單來說核心思路就兩條要么讓瀏覽器“認(rèn)為”請(qǐng)求沒有跨域要么明確告訴瀏覽器“這個(gè)跨域請(qǐng)求我允許你帶Cookie”。本文將深入拆解這兩種方式的原理、具體實(shí)現(xiàn)步驟以及我踩過的那些坑無論你是用Vue、React還是純后端開發(fā)都能找到可直接復(fù)現(xiàn)的解決方案。2. 核心思路拆解兩種路徑的本質(zhì)區(qū)別面對(duì)Cookie跨域問題技術(shù)方案看似繁多但歸根結(jié)底可以劃分為兩種根本性的解決路徑。理解這兩種路徑背后的設(shè)計(jì)哲學(xué)和適用邊界比死記硬背配置更重要。2.1 路徑一同源化代理——繞過瀏覽器的同源策略這是最徹底、也是最“省心”的一種思路。既然瀏覽器同源策略是問題的根源那么我們就創(chuàng)造一個(gè)“中間人”讓瀏覽器所有的請(qǐng)求都發(fā)向同一個(gè)源域名、端口、協(xié)議均相同。實(shí)現(xiàn)原理我們在前端應(yīng)用所在的服務(wù)器或開發(fā)服務(wù)器上架設(shè)一個(gè)反向代理。所有以前端域名為起點(diǎn)的、目標(biāo)為后端API的請(qǐng)求都被這個(gè)代理服務(wù)攔截并轉(zhuǎn)發(fā)。對(duì)于瀏覽器而言它始終是在和前端域名通信完全感知不到后端API域名的存在自然也就不存在跨域問題Cookie的發(fā)送和接收遵循最標(biāo)準(zhǔn)的同源規(guī)則暢通無阻。核心優(yōu)勢對(duì)前端代碼零侵入前端代碼中的API請(qǐng)求地址可以直接寫成相對(duì)路徑如/api/user或完整的前端域名地址無需任何跨域相關(guān)配置。開發(fā)體驗(yàn)純粹。安全性更高Cookie的SameSite、HttpOnly、Secure等屬性可以保持最嚴(yán)格的設(shè)置因?yàn)檎?qǐng)求沒有跨域這些安全策略不會(huì)成為障礙。部署靈活無論是開發(fā)階段的Webpack DevServer代理還是生產(chǎn)環(huán)境的Nginx/Apache反向代理配置模式統(tǒng)一易于理解和維護(hù)。適用場景這是現(xiàn)代前后端分離項(xiàng)目特別是單頁應(yīng)用SPA的首選推薦方案。無論是開發(fā)環(huán)境還是生產(chǎn)環(huán)境都強(qiáng)烈建議優(yōu)先采用此方案。2.2 路徑二CORS標(biāo)準(zhǔn)化協(xié)作——與瀏覽器明確協(xié)商當(dāng)同源化代理不可行時(shí)例如前端是靜態(tài)托管在CDN無法自定義代理規(guī)則或者后端服務(wù)需要被多個(gè)不同域名的前端直接調(diào)用我們就必須正面解決跨域問題。此時(shí)需要后端服務(wù)與瀏覽器進(jìn)行一場“標(biāo)準(zhǔn)化的協(xié)商”這就是跨源資源共享CORS。實(shí)現(xiàn)原理CORS是一套W3C標(biāo)準(zhǔn)。當(dāng)瀏覽器檢測到當(dāng)前頁面向不同源的服務(wù)器發(fā)起請(qǐng)求時(shí)它會(huì)自動(dòng)在請(qǐng)求頭中添加一個(gè)Origin字段標(biāo)明請(qǐng)求來源。后端服務(wù)器必須明確響應(yīng)通過一系列以Access-Control-*開頭的HTTP頭部來聲明允許哪些來源、方法、頭部以及是否允許攜帶憑證如Cookie。核心要點(diǎn)對(duì)于攜帶Cookie的跨域請(qǐng)求有兩個(gè)必須同時(shí)滿足的關(guān)鍵條件前端請(qǐng)求必須設(shè)置withCredentials: true在Fetch API或Axios中。后端響應(yīng)必須包含Access-Control-Allow-Credentials: true并且Access-Control-Allow-Origin頭部不能是通配符*必須明確指定為請(qǐng)求的Origin值。適用場景多前端域名共享同一后端服務(wù)、第三方調(diào)用、或者無法控制前端部署環(huán)境如移動(dòng)端Hybrid App內(nèi)嵌的WebView直接調(diào)用公網(wǎng)API等情況。注意路徑二CORS是解決跨域問題的通用標(biāo)準(zhǔn)但涉及Cookie時(shí)配置更為嚴(yán)格。路徑一代理并非“解決”了CORS問題而是從根本上“避免”了跨域場景的發(fā)生。3. 方案一詳解同源化代理配置實(shí)戰(zhàn)讓我們先從實(shí)踐角度更強(qiáng)的代理方案開始。我將分別演示在開發(fā)環(huán)境和生產(chǎn)環(huán)境下的配置方法。3.1 開發(fā)環(huán)境基于Vite/Webpack DevServer的代理如果你使用Vue 3 Vite 或 React Webpack開發(fā)服務(wù)器內(nèi)置的代理功能是最高效的工具。Vite 項(xiàng)目配置vite.config.jsimport { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { proxy: { // 代理規(guī)則鍵名你想要攔截的請(qǐng)求路徑前綴 /api: { target: http://api.your-domain.com:8080, // 實(shí)際的后端API地址 changeOrigin: true, // 必須設(shè)置為true虛擬主機(jī)站點(diǎn) rewrite: (path) path.replace(/^\/api/, ), // 可選重寫路徑。如果后端接口沒有/api前綴可以去掉 // 通常不需要配置cookie相關(guān)因?yàn)橛蛎呀y(tǒng)一 }, // 你可以配置多個(gè)代理規(guī)則 /auth: { target: http://auth.your-domain.com:9090, changeOrigin: true, } } } })關(guān)鍵參數(shù)解析target你要代理到的真實(shí)后端地址。changeOrigin: true這是靈魂配置。它會(huì)把代理請(qǐng)求的Host頭修改為target的域名。很多后端服務(wù)尤其是基于虛擬主機(jī)或需要驗(yàn)證Host頭的框架沒有這個(gè)選項(xiàng)會(huì)返回404或403錯(cuò)誤。rewrite路徑重寫。如果你的前端請(qǐng)求是/api/users但后端實(shí)際接口是/users就可以用path.replace(/^\/api/, )去掉前綴。Webpack 項(xiàng)目配置vue.config.js或webpack.config.jsmodule.exports { devServer: { proxy: { /api: { target: http://localhost:3000, // 后端服務(wù)地址 changeOrigin: true, pathRewrite: { ^/api: }, // Webpack中使用pathRewrite // secure: false, // 如果目標(biāo)是https但證書不受信任可設(shè)置為false僅開發(fā)環(huán)境 } } } }實(shí)操心得啟動(dòng)后測試配置完成后重啟你的開發(fā)服務(wù)器。在瀏覽器中訪問http://localhost:5173/api/test假設(shè)前端運(yùn)行在5173端口。打開瀏覽器開發(fā)者工具的“網(wǎng)絡(luò)Network”選項(xiàng)卡你應(yīng)該看到這個(gè)請(qǐng)求的URL顯示為http://localhost:5173/api/test但響應(yīng)數(shù)據(jù)來自后端服務(wù)器。請(qǐng)求頭中不會(huì)出現(xiàn)Origin因?yàn)閷?duì)瀏覽器而言這并非跨域請(qǐng)求。Cookie自動(dòng)攜帶由于請(qǐng)求域名現(xiàn)在是localhost之前由localhost后端或代理轉(zhuǎn)發(fā)后由真實(shí)后端設(shè)置的Cookie會(huì)被瀏覽器自動(dòng)存儲(chǔ)并在下次向localhost發(fā)起請(qǐng)求時(shí)攜帶完美閉環(huán)。3.2 生產(chǎn)環(huán)境基于Nginx的反向代理配置生產(chǎn)環(huán)境中前端通常是編譯后的靜態(tài)文件由Nginx這類高性能Web服務(wù)器托管。同時(shí)Nginx也承擔(dān)反向代理的職責(zé)。一個(gè)典型的Nginx配置片段如下server { listen 80; server_name app.your-domain.com; # 你的前端域名 # 靜態(tài)文件服務(wù) location / { root /usr/share/nginx/html; # 前端構(gòu)建產(chǎn)物目錄 index index.html index.htm; try_files $uri $uri/ /index.html; # 支持SPA歷史模式 } # 反向代理到后端API location /api/ { proxy_pass http://backend-server:8080/; # 后端服務(wù)地址結(jié)尾的/很重要 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 以下兩行對(duì)于WebSocket代理或某些需要原始主機(jī)頭的應(yīng)用可能重要但常規(guī)API代理非必須 # proxy_set_header Upgrade $http_upgrade; # proxy_set_header Connection upgrade; # Cookie和重定向相關(guān)確保正確處理 proxy_cookie_path / /; # 如果后端設(shè)置的Cookie路徑需要調(diào)整可在此修改 # proxy_cookie_domain backend-domain.com app.your-domain.com; # 修改Cookie的Domain慎用 } # 可以代理多個(gè)路徑 location /auth/ { proxy_pass http://auth-server:9090/; proxy_set_header Host $host; # ... 其他頭部設(shè)置 } }關(guān)鍵指令解析proxy_pass核心指令定義上游服務(wù)器地址。注意地址末尾的/如果配置為http://backend-server:8080/那么請(qǐng)求/api/user會(huì)被轉(zhuǎn)發(fā)為http://backend-server:8080/user。如果沒有/則轉(zhuǎn)發(fā)為http://backend-server:8080/api/user。務(wù)必與后端路由匹配。proxy_set_header用于修改轉(zhuǎn)發(fā)給后端請(qǐng)求的頭部信息。Host、X-Real-IP、X-Forwarded-For是傳遞客戶端真實(shí)信息的標(biāo)準(zhǔn)做法對(duì)于后端日志記錄和安全審計(jì)至關(guān)重要。proxy_cookie_path和proxy_cookie_domain在絕大多數(shù)情況下你不需要配置它們。只有當(dāng)后端設(shè)置的Cookie路徑Path或域名Domain與代理環(huán)境不匹配導(dǎo)致瀏覽器無法正確存儲(chǔ)和發(fā)送Cookie時(shí)才需要考慮使用它們來重寫Cookie屬性。我的經(jīng)驗(yàn)是先不配出了問題再針對(duì)性調(diào)整。配置后的驗(yàn)證將你的前端代碼構(gòu)建并放入Nginx的root目錄。配置DNS將app.your-domain.com指向Nginx服務(wù)器IP。訪問https://app.your-domain.com進(jìn)行登錄操作。觀察網(wǎng)絡(luò)請(qǐng)求所有/api/開頭的請(qǐng)求都應(yīng)指向app.your-domain.com并且請(qǐng)求頭中會(huì)自動(dòng)包含之前登錄設(shè)置的Cookie。4. 方案二詳解CORS標(biāo)準(zhǔn)協(xié)作配置實(shí)戰(zhàn)當(dāng)必須直面跨域時(shí)CORS是唯一的標(biāo)準(zhǔn)解決方案。這里需要前端和后端協(xié)同配置。4.1 后端服務(wù)CORS配置以Node.js/Express和Spring Boot為例后端配置是CORS能否成功的關(guān)鍵特別是涉及憑證Cookie時(shí)。Node.js Express 后端配置const express require(express); const cors require(cors); // 使用cors中間件 const app express(); // 配置CORS選項(xiàng) const corsOptions { origin: function (origin, callback) { // 允許的源列表生產(chǎn)環(huán)境應(yīng)具體配置避免使用 * const allowedOrigins [https://app.your-domain.com, http://localhost:5173]; if (!origin || allowedOrigins.indexOf(origin) ! -1) { // 如果請(qǐng)求沒有origin頭如curl或origin在允許列表中則通過 callback(null, true); } else { callback(new Error(Not allowed by CORS)); } }, credentials: true, // 這是允許攜帶Cookie的關(guān)鍵 allowedHeaders: [Content-Type, Authorization], // 允許的請(qǐng)求頭 methods: [GET, POST, PUT, DELETE, OPTIONS], // 允許的HTTP方法 }; // 應(yīng)用CORS中間件 app.use(cors(corsOptions)); // 或者對(duì)特定路由應(yīng)用 // app.get(/api/data, cors(corsOptions), (req, res) {...}); // 你的路由 app.post(/api/login, (req, res) { // 登錄邏輯... res.cookie(auth_token, your_token_here, { httpOnly: true, secure: process.env.NODE_ENV production, // 生產(chǎn)環(huán)境用HTTPS sameSite: none, // 跨域Cookie必須設(shè)置為 none同時(shí)Secure必須為true maxAge: 24 * 60 * 60 * 1000 // 1天 }); res.json({ success: true }); }); app.listen(3000, () console.log(Server running on port 3000));Spring Boot 后端配置import org.springframework.context.annotation.Bean; 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(/api/**) // 配置應(yīng)用于哪些路徑 .allowedOrigins(https://app.your-domain.com, http://localhost:5173) // 允許的源不能是 * .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) // 允許所有頭或具體指定 .allowCredentials(true) // 這是允許攜帶Cookie的關(guān)鍵 .maxAge(3600); // 預(yù)檢請(qǐng)求緩存時(shí)間秒 } }關(guān)于Cookie屬性的致命細(xì)節(jié) 當(dāng)使用CORS跨域傳遞Cookie時(shí)后端在設(shè)置Cookie的響應(yīng)頭中SameSite屬性必須設(shè)置為None并且Secure屬性必須設(shè)置為true。這意味著你的網(wǎng)站必須使用HTTPS。在本地開發(fā)環(huán)境HTTP下瀏覽器會(huì)拒絕存儲(chǔ)這樣的Cookie這是安全策略。本地開發(fā)時(shí)可以暫時(shí)將SameSite設(shè)為Lax或Strict并關(guān)閉Secure但務(wù)必記得在生產(chǎn)環(huán)境改回來。4.2 前端請(qǐng)求配置以Fetch和Axios為例后端允許了前端也必須明確聲明“我要發(fā)送憑證”。使用原生Fetch APIfetch(https://api.your-domain.com/login, { method: POST, headers: { Content-Type: application/json, }, body: JSON.stringify({ username, password }), credentials: include, // 關(guān)鍵包含Cookie等憑證 }) .then(response response.json()) .then(data console.log(data));使用Axios庫更常見import axios from axios; // 方式1創(chuàng)建配置了withCredentials的實(shí)例推薦 const apiClient axios.create({ baseURL: https://api.your-domain.com, withCredentials: true, // 關(guān)鍵跨域請(qǐng)求攜帶Cookie timeout: 10000, }); // 使用這個(gè)實(shí)例發(fā)起請(qǐng)求會(huì)自動(dòng)攜帶Cookie apiClient.post(/login, { username, password }); // 方式2在單個(gè)請(qǐng)求中配置 axios.post(https://api.your-domain.com/login, { username, password }, { withCredentials: true } );關(guān)鍵點(diǎn)withCredentials: trueAxios或credentials: includeFetch是前端必須設(shè)置的選項(xiàng)。不設(shè)置這個(gè)即使后端配置了Allow-Credentials瀏覽器也不會(huì)發(fā)送Cookie。5. 深度對(duì)比與選型決策指南兩種方案各有優(yōu)劣選擇哪一種取決于你的具體架構(gòu)、團(tuán)隊(duì)技能和運(yùn)維條件。特性維度同源化代理方案CORS標(biāo)準(zhǔn)協(xié)作方案核心原理在服務(wù)器端統(tǒng)一請(qǐng)求源規(guī)避跨域。前后端遵循CORS標(biāo)準(zhǔn)協(xié)商解決跨域。前端復(fù)雜度極低。無需任何跨域配置API地址簡單。中等。需配置withCredentials并處理可能的預(yù)檢請(qǐng)求。后端復(fù)雜度低。后端無需特殊CORS配置按標(biāo)準(zhǔn)API開發(fā)即可。高。需精確配置CORS策略特別是Origin白名單和憑證允許。安全性高。Cookie屬性可保持嚴(yán)格HttpOnly, Secure, SameSiteStrict。中。需放寬Cookie的SameSite策略設(shè)為None且Origin白名單管理不當(dāng)有風(fēng)險(xiǎn)。部署運(yùn)維中等。需維護(hù)反向代理Nginx配置。簡單。前后端獨(dú)立部署僅需后端配置CORS。適用場景前后端項(xiàng)目由同一團(tuán)隊(duì)掌控部署環(huán)境可統(tǒng)一規(guī)劃。SPA項(xiàng)目首選。后端API需被多個(gè)不同域的前端調(diào)用如公開API、多平臺(tái)應(yīng)用。前后端獨(dú)立部署且無法代理。本地開發(fā)非常方便開發(fā)服務(wù)器代理輕松配置。需注意HTTP環(huán)境下Cookie的Secure限制可能需特殊處理。我的選型建議對(duì)于絕大多數(shù)企業(yè)級(jí)前后端分離項(xiàng)目優(yōu)先采用方案一同源化代理。它在開發(fā)、測試、生產(chǎn)環(huán)境能提供一致的行為安全性更好前端開發(fā)心智負(fù)擔(dān)小。將跨域問題在基礎(chǔ)設(shè)施層解決是更優(yōu)雅的架構(gòu)。僅在以下情況考慮方案二CORS后端是純API服務(wù)需要被來自多個(gè)不可控域名的第三方前端調(diào)用。前端是靜態(tài)頁面托管在GitHub Pages、Vercel、Netlify等無法自定義反向代理的平臺(tái)上。微服務(wù)架構(gòu)中某個(gè)中間層服務(wù)需要直接跨域調(diào)用另一個(gè)服務(wù)的API且無法通過網(wǎng)關(guān)統(tǒng)一代理。6. 常見問題排查與實(shí)戰(zhàn)技巧實(shí)錄在實(shí)際操作中即使按照步驟配置也難免遇到問題。這里記錄了我遇到的一些典型“坑”及其解決方法。6.1 Cookie未成功攜帶或設(shè)置問題現(xiàn)象登錄請(qǐng)求成功響應(yīng)頭里有Set-Cookie但后續(xù)請(qǐng)求的請(qǐng)求頭里沒有Cookie或者瀏覽器根本沒有存儲(chǔ)這個(gè)Cookie。排查清單檢查前端withCredentials確保你的Axios實(shí)例或Fetch調(diào)用設(shè)置了withCredentials: true。這是最常被忽略的一步。檢查后端CORS響應(yīng)頭響應(yīng)頭必須包含Access-Control-Allow-Credentials: true。Access-Control-Allow-Origin的值必須是具體的來源如https://app.your-domain.com絕對(duì)不能是通配符*。如果允許多個(gè)源需要在后端動(dòng)態(tài)判斷Origin請(qǐng)求頭并返回對(duì)應(yīng)的值。檢查Cookie屬性CORS方案下Secure屬性如果前端使用HTTPS后端設(shè)置的Cookie必須有Secure屬性。本地開發(fā)用HTTP時(shí)需要暫時(shí)去掉Secure。SameSite屬性跨域請(qǐng)求下Cookie的SameSite必須設(shè)置為None。同時(shí)SameSiteNone必須和Securetrue同時(shí)出現(xiàn)。Domain和Path確保Cookie的Domain和Path設(shè)置正確能被目標(biāo)請(qǐng)求訪問到。在代理方案中如果代理修改了路徑可能需要proxy_cookie_path調(diào)整。瀏覽器開發(fā)者工具檢查Application Cookies查看Cookie是否被成功存儲(chǔ)。檢查其Domain、Path、Secure、SameSite屬性。Network查看請(qǐng)求是否被標(biāo)記為跨域請(qǐng)求檢查請(qǐng)求頭是否有Origin響應(yīng)頭是否有正確的CORS頭部。6.2 預(yù)檢請(qǐng)求Preflight Request失敗問題現(xiàn)象對(duì)于非簡單請(qǐng)求如Content-Type為application/json的POST請(qǐng)求瀏覽器會(huì)先發(fā)送一個(gè)OPTIONS方法的預(yù)檢請(qǐng)求。如果這個(gè)請(qǐng)求失敗真正的請(qǐng)求就不會(huì)發(fā)出。解決方案后端必須正確處理OPTIONS請(qǐng)求確保你的后端路由或CORS中間件能夠響應(yīng)OPTIONS方法并返回正確的CORS頭部。檢查Access-Control-Allow-Headers如果前端請(qǐng)求包含了自定義頭部如Authorization必須在后端的Access-Control-Allow-Headers響應(yīng)頭中列出它或者使用通配符*但注意當(dāng)credentials為true時(shí)通配符可能被瀏覽器限制。檢查Access-Control-Allow-Methods確保它包含了前端實(shí)際使用的HTTP方法。6.3 代理配置后出現(xiàn)404或502錯(cuò)誤問題現(xiàn)象配置了Nginx或開發(fā)服務(wù)器代理后API請(qǐng)求返回404 Not Found或502 Bad Gateway。排查步驟檢查proxy_pass地址確認(rèn)上游服務(wù)后端的地址、端口、路徑是否正確并且服務(wù)正在運(yùn)行。檢查proxy_pass末尾斜杠這是Nginx配置的一個(gè)經(jīng)典坑。proxy_pass http://backend/;和proxy_pass http://backend;的行為完全不同會(huì)影響請(qǐng)求URI的轉(zhuǎn)發(fā)。根據(jù)后端路由規(guī)則仔細(xì)調(diào)整。檢查后端服務(wù)是否綁定了正確的主機(jī)有些后端框架如Spring Boot默認(rèn)只綁定localhost。當(dāng)從其他服務(wù)器如Nginx代理過來時(shí)需要將服務(wù)綁定到0.0.0.0。查看Nginx錯(cuò)誤日志/var/log/nginx/error.log通常會(huì)給出更詳細(xì)的錯(cuò)誤信息如連接被拒絕等。6.4 本地開發(fā)環(huán)境下的特殊處理在本地開發(fā)時(shí)前端可能運(yùn)行在http://localhost:3000后端運(yùn)行在http://localhost:8080。雖然域名都是localhost但端口不同瀏覽器依然認(rèn)為是跨域。方案選擇首選代理在Vite/Webpack中配置代理將/api代理到http://localhost:8080。這是最干凈的方式。使用CORS如果必須用CORS后端需要將http://localhost:3000加入允許的Origin列表。同時(shí)由于是HTTP協(xié)議后端設(shè)置Cookie時(shí)不能包含Secure屬性否則瀏覽器會(huì)拒絕存儲(chǔ)。SameSite可以暫時(shí)設(shè)為Lax。一個(gè)實(shí)用的本地開發(fā)CORS配置Node.js示例const corsOptions { origin: function (origin, callback) { // 開發(fā)環(huán)境寬松處理允許所有本地源 if (!origin || origin.startsWith(http://localhost:)) { callback(null, true); } else { // 生產(chǎn)環(huán)境嚴(yán)格校驗(yàn) callback(new Error(Not allowed by CORS)); } }, credentials: true, }; app.use(cors(corsOptions)); // 在設(shè)置Cookie的中間件或路由中根據(jù)環(huán)境判斷 app.use((req, res, next) { // 假設(shè)通過環(huán)境變量判斷 const isProduction process.env.NODE_ENV production; res.cookie(token, value, { httpOnly: true, secure: isProduction, // 生產(chǎn)環(huán)境true開發(fā)環(huán)境false sameSite: isProduction ? none : lax, // 生產(chǎn)環(huán)境none開發(fā)環(huán)境lax }); next(); });通過以上兩種方式的詳細(xì)拆解和實(shí)戰(zhàn)問題排查相信你已經(jīng)對(duì)Cookie跨域共享有了全面且深入的理解。記住沒有最好的方案只有最適合你當(dāng)前項(xiàng)目階段和架構(gòu)的方案。從代理方案入手往往能讓你的開發(fā)之路更加平坦。