1. 同源策略前端世界的“安全門衛”做前端開發只要和瀏覽器打交道就繞不開“同源策略”這四個字。它就像瀏覽器內置的一位鐵面無私的門衛時刻審視著每一個進出頁面的請求決定是放行還是攔截。簡單來說同源策略是一種核心的安全機制它規定了一個源Origin加載的文檔或腳本如何與另一個源的資源進行交互。它的存在從根本上防止了惡意網站竊取用戶在其他網站比如你的銀行或郵箱的敏感數據。對于前端開發者而言理解這位“門衛”的規則并學會在合規的前提下與“鄰居”其他源安全通信是一項必備技能。那么什么是“同源”判斷標準非常嚴格必須同時滿足三個要素完全相同協議、域名、端口。只要有一個不同就被視為“跨源”或我們常說的“跨域”。舉個例子https://www.example.com:443這個源它與以下地址的關系是https://www.example.com:8080-不同源端口不同http://www.example.com:443-不同源協議不同https://api.example.com:443-不同源域名不同子域名也算不同源https://www.example.com:443/path/to/page-同源僅路徑不同不影響同源判斷這位“門衛”主要限制以下幾種行為1) 無法讀取非同源網頁的 Cookie、LocalStorage 和 IndexedDB2) 無法獲取非同源網頁的 DOM 元素典型的如iframe嵌套不同源頁面3) 限制通過XMLHttpRequest或Fetch API發起的跨源 HTTP 請求。最后一點正是我們日常開發中遇到“跨域問題”最常見的場景。當你從localhost:3000的前端項目去請求localhost:8080的后端 API 時瀏覽器控制臺那個經典的CORS policy錯誤就出現了。理解它不是為了對抗它而是為了在它的規則下安全、優雅地實現業務需求。1.1 為什么需要同源策略一個生動的比喻為了更直觀地理解我們可以把互聯網想象成一個巨大的社區每個網站源就是社區里的一棟房子。你的房子https://your-bank.com里有你的保險柜Cookie、登錄態、私人文件DOM和電話AJAX請求。如果沒有同源策略這個社區保安會發生什么一個偽裝成送快遞的惡意網站http://evil-site.com可以輕易地打開你家的窗戶通過腳本偷看你的保險柜密碼翻閱你的私人文件甚至用你的電話冒充你給銀行打電話轉賬。這無疑是災難性的。同源策略的作用就是給每棟房子裝上安全鎖和監控。它規定只有從你自己房子內部發出的指令才能操作你自己房子的東西。來自其他房子的快遞員腳本只能按門鈴發起請求但未經你明確許可CORS機制絕對不能進門更不能亂動你的物品。這樣即使你不小心訪問了惡意網站它也無法直接竊取你在其他重要網站如銀行、郵箱的會話信息極大地保護了用戶的數據安全和隱私。作為開發者我們的任務不是拆掉這把鎖而是學會如何正確地使用“訪客登記系統”讓合法的、我們需要的“訪客”如后端API、第三方服務能夠安全地進來。1.2 跨域請求的典型場景與錯誤在實際開發中跨域請求無處不在尤其是在前后端分離的架構下。以下是一些典型場景本地開發前端運行在http://localhost:3000后端 API 服務運行在http://localhost:8080。多環境部署Web 應用部署在https://www.myapp.com而靜態資源圖片、字體或 API 服務器部署在獨立的域名https://cdn.myapp.com或https://api.myapp.com。第三方服務集成你的網站需要調用地圖 API如高德、百度、支付接口如支付寶、微信支付、社交登錄如微信、微博 OAuth等這些服務的域名與你自己的站點域名必然不同。當瀏覽器攔截了一個跨域請求時你會在開發者工具的 Console 或 Network 面板中看到明確的錯誤信息。最常見的就是 CORS 相關錯誤例如Access to fetch at ‘https://api.example.com/data‘ from origin ‘https://www.myapp.com‘ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin‘ header is present on the requested resource.或者更詳細的預檢請求錯誤Access to fetch at ... has been blocked by CORS policy: Response to preflight request doesn‘t pass access control check: It does not have HTTP ok status.這些紅色的錯誤日志正是同源策略這位“門衛”在盡職盡責地提醒你當前請求未獲得目標服務器的明確許可。解決這些錯誤就是我們接下來要探討的核心。2. 經典跨域解決方案深度剖析面對跨域限制前端社區發展出了多種解決方案。每種方案都有其特定的適用場景、實現原理和優缺點。我們不能只會調用axios或fetch更要理解背后發生了什么。這里我們深入剖析幾種最經典、最常用的方案。2.1 JSONP基于script標簽的“歷史智慧”JSONPJSON with Padding是一種非常古老但一度非常流行的跨域技術。它巧妙地利用了 HTML 中script標簽的一個特性其src屬性可以跨域加載 JavaScript 文件。瀏覽器不會對script標簽的跨域加載施加同源策略限制。實現原理前端不直接發起 AJAX 請求而是動態創建一個script標簽。將這個script標簽的src屬性設置為目標 API 的 URL并在 URL 上通過查詢參數通常是callback指定一個全局回調函數名例如https://api.example.com/data?callbackhandleResponse。將這個script標簽插入到 DOM 中瀏覽器就會去請求這個 URL。服務器端需要配合這個約定。它接收到請求后不是返回標準的 JSON而是返回一段JavaScript 代碼這段代碼的內容是調用前端指定的那個回調函數并將真正的數據作為參數傳入。例如返回handleResponse({status: ok, data: {...}})。瀏覽器加載并執行這段返回的 JS 代碼自然就調用了前端的handleResponse函數數據就這樣“跨域”傳遞過來了。一個簡單的實現示例function jsonp(url, callbackName) { return new Promise((resolve, reject) { // 創建全局回調函數函數名需唯一 const funcName jsonpCallback_${Date.now()}; window[funcName] function(data) { resolve(data); // 清理工作 document.body.removeChild(script); delete window[funcName]; }; // 創建script標簽 const script document.createElement(script); script.src ${url}${url.includes(?) ? : ?}callback${funcName}; script.onerror reject; // 處理加載失敗 document.body.appendChild(script); }); } // 使用 jsonp(https://api.example.com/data, handleData) .then(data console.log(data)) .catch(err console.error(請求失敗, err));注意事項與局限僅支持 GET 請求這是 JSONP 最致命的限制因為它本質上是加載一個腳本資源。安全性問題由于引入了外部動態腳本如果服務器被攻破或返回惡意代碼前端會直接執行存在 XSS跨站腳本攻擊風險。必須絕對信任服務器。錯誤處理困難script標簽的onerror事件能捕獲網絡錯誤但難以處理服務器返回的業務邏輯錯誤比如 HTTP 200 但返回了錯誤信息。需要服務器端特殊支持后端必須能夠解析callback參數并返回特定格式的 JS 代碼。正在被淘汰在現代 Web 開發中隨著 CORS 標準的完善和廣泛支持JSONP 已逐漸淡出主流視野更多作為一種“歷史知識”或在不支持 CORS 的極端老舊環境中使用。2.2 CORS現代跨域通信的“官方協議”CORSCross-Origin Resource Sharing跨源資源共享是 W3C 標準屬于“官方解決方案”。它允許服務器聲明哪些源可以訪問其資源從而在遵守同源策略的前提下安全地進行跨域通信。CORS 的關鍵在于服務器端的響應頭前端發起的請求本身并無特殊除了會多發送一些頭信息。CORS 請求的分類 CORS 請求分為兩類簡單請求和非簡單請求需預檢的請求。瀏覽器會自動處理這種區分。簡單請求滿足以下所有條件的請求。方法為 GET、HEAD、POST 之一。請求頭僅包含Accept,Accept-Language,Content-Language,Content-Type值僅限于application/x-www-form-urlencoded,multipart/form-data,text/plain。沒有使用ReadableStream對象等。 對于簡單請求瀏覽器直接發出跨域請求并在請求頭中自動添加一個Origin字段表明請求來自哪個源。服務器需要檢查這個Origin如果允許就在響應頭中包含Access-Control-Allow-Origin: Origin值或*。瀏覽器看到這個響應頭就會允許前端代碼訪問響應內容。非簡單請求/預檢請求不滿足簡單請求條件的請求例如使用了PUT、DELETE方法或Content-Type為application/json或設置了自定義頭如Authorization。 對于這類請求瀏覽器會先使用OPTIONS方法發起一個“預檢請求”Preflight Request到服務器以獲知服務器是否允許該實際請求。預檢請求的頭部會包含Access-Control-Request-Method: 告知服務器實際請求將使用的方法。Access-Control-Request-Headers: 告知服務器實際請求將攜帶的自定義頭。 服務器必須響應這個 OPTIONS 請求并在響應頭中明確聲明允許的方法、頭、源等。只有預檢請求通過后瀏覽器才會發出真正的請求。服務器端 CORS 配置示例以 Node.js Express 為例 一個完整且在生產中建議進行細粒度控制的 CORS 中間件配置如下const express require(express); const app express(); // 允許的源列表生產環境應具體指定避免使用 * const allowedOrigins [https://www.myapp.com, https://admin.myapp.com, http://localhost:3000]; app.use((req, res, next) { const origin req.headers.origin; // 檢查請求源是否在允許列表中 if (allowedOrigins.includes(origin)) { res.setHeader(Access-Control-Allow-Origin, origin); // 動態設置允許的源 } // 或者為了簡單測試可以暫時允許所有源不推薦生產環境 // res.setHeader(Access-Control-Allow-Origin, *); // 允許客戶端攜帶的請求頭如 Authorization, Content-Type res.setHeader(Access-Control-Allow-Headers, Content-Type, Authorization, X-Requested-With); // 允許的 HTTP 方法 res.setHeader(Access-Control-Allow-Methods, GET, POST, PUT, PATCH, DELETE, OPTIONS); // 允許瀏覽器暴露哪些響應頭給前端 JavaScript如 Authorization res.setHeader(Access-Control-Expose-Headers, Authorization); // 允許跨域請求攜帶 Cookie對應前端 fetch 需要設置 credentials: include res.setHeader(Access-Control-Allow-Credentials, true); // 預檢請求緩存時間秒減少 OPTIONS 請求 res.setHeader(Access-Control-Max-Age, 86400); // 24小時 // 如果是 OPTIONS 預檢請求直接返回 200 if (req.method OPTIONS) { return res.sendStatus(200); } next(); }); // ... 你的其他路由 app.listen(8080);前端發起 CORS 請求 使用fetchAPI 時默認行為對于簡單請求是透明的。對于需要憑證Cookies或自定義頭的請求需進行配置。// 攜帶 Cookie 的請求 fetch(https://api.example.com/data, { method: GET, credentials: include, // 關鍵告訴瀏覽器攜帶 Cookie headers: { Content-Type: application/json, Authorization: Bearer ${token} // 自定義頭會觸發預檢 } }) .then(response response.json()) .then(data console.log(data)); // 使用 axios axios.get(https://api.example.com/data, { withCredentials: true, // 等效于 fetch 的 credentials: include headers: { Authorization: Bearer ${token} } });實操心得不要濫用*在生產環境中Access-Control-Allow-Origin: *與Access-Control-Allow-Credentials: true是互斥的。如果允許憑證源必須明確指定不能是通配符*。理解預檢遇到CORS preflight錯誤時首先檢查服務器是否正確響應了OPTIONS請求并設置了正確的Allow-Methods和Allow-Headers。緩存預檢合理設置Access-Control-Max-Age可以減少不必要的 OPTIONS 請求提升性能。錯誤處理CORS 錯誤發生在網絡層面fetch或axios的catch可能捕獲不到瀏覽器直接攔截。需要結合 Network 面板查看具體的請求和響應頭來調試。2.3 服務器代理前端的“萬能鑰匙”當你不方便修改后端服務的 CORS 配置例如調用第三方 API對方未設置 CORS 頭或者開發環境想徹底避開瀏覽器限制時服務器代理是一個極其有效的方案。其原理很簡單讓同源的服務器端去發起跨域請求然后將結果返回給前端。因為同源策略只限制瀏覽器不限制服務器。實現方式開發服務器代理現代前端構建工具如 Vite、Webpack Dev Server都內置了強大的代理功能。Vite 示例(vite.config.js)export default defineConfig({ server: { proxy: { // 將 /api 開頭的請求代理到目標服務器 /api: { target: http://localhost:8080, // 后端 API 地址 changeOrigin: true, // 修改請求頭中的 Host 為目標地址通常需要開啟 rewrite: (path) path.replace(/^\/api/, ) // 重寫路徑可選 } } } })配置后前端代碼中請求/api/users實際上會被 Vite 開發服務器代理到http://localhost:8080/users完美繞過瀏覽器跨域。Webpack Dev Server 示例(webpack.config.js)module.exports { // ... devServer: { proxy: { /api: http://localhost:8080 } } };生產環境反向代理在生產環境中通常使用 Nginx 或 Apache 等 Web 服務器作為反向代理。Nginx 配置示例server { listen 80; server_name www.myapp.com; location / { root /path/to/your/frontend/dist; index index.html; try_files $uri $uri/ /index.html; # 用于支持前端路由 } # 代理到后端 API 服務器 location /api/ { proxy_pass http://backend-server:8080/; # 后端服務地址 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; } }這樣用戶訪問www.myapp.comNginx 服務前端靜態文件當前端請求www.myapp.com/api/xxx時Nginx 會將其透明地轉發到內部的backend-server:8080上對瀏覽器而言所有請求都是同源的。注意事項非銀彈代理解決的是前端開發時的跨域問題或者在生產中統一入口。它并沒有改變跨域的本質只是把跨域請求的發起者從瀏覽器移到了服務器。安全性如果代理的是不受信任的第三方服務需要小心處理請求和響應防止被用作攻擊跳板。Cookie 與頭信息配置代理時需要注意正確傳遞原始請求的 Cookie、認證頭等信息如上述 Nginx 配置中的proxy_set_header。3. 其他跨域技術與實戰場景除了上述三大主流方案還有一些特定場景下使用的跨域技術了解它們可以讓你在遇到特殊問題時多一種思路。3.1postMessage跨文檔通信的“標準通道”window.postMessage()方法提供了一種安全的、受控的機制允許不同源的窗口/iframe 之間進行通信。這在需要嵌入第三方組件如地圖、支付、客服插件或實現多頁面應用通信時非常有用。基本用法// 發送方 (例如父頁面) const iframe document.getElementById(myIframe); const targetWindow iframe.contentWindow; const targetOrigin https://trusted-site.com; // 必須指定目標源出于安全考慮 // 發送消息 targetWindow.postMessage({ type: USER_DATA, payload: userInfo }, targetOrigin); // 接收方 (例如 iframe 內的頁面) window.addEventListener(message, (event) { // 重要務必驗證消息來源 if (event.origin ! https://parent-site.com) { // 忽略來自未知源的消息 return; } console.log(收到消息:, event.data); // 處理消息... });關鍵點安全性postMessage的第一個參數targetOrigin和接收方的event.origin檢查至關重要可以防止惡意網站攔截或發送偽造消息。異步通信是異步的基于事件監聽。結構化克隆算法可以傳遞能夠被結構化克隆算法處理的任何對象包括大多數原生類型、對象、數組但不能傳遞函數、DOM 元素等。3.2 修改document.domain同主域下的“捷徑”這是一個非常受限且逐漸被廢棄的方法。它只適用于一種特殊情況兩個頁面擁有相同的頂級域名和相同的二級域名只是子域名不同。例如a.example.com和b.example.com。原理通過將兩個頁面的document.domain都設置為example.com瀏覽器會認為它們同源從而允許直接訪問彼此的 DOM 和 Cookie。// 在 a.example.com 和 b.example.com 的頁面中都執行 document.domain example.com;嚴重限制只能設置為當前域或其父域。一旦設置無法再改回更具體的子域。端口號會被忽略如果端口不同仍可能有問題。現代瀏覽器出于安全考慮對此方法的限制越來越多不推薦在新項目中使用。3.3 WebSocket不受同源策略限制的“特例”WebSocket 協議 (ws://或wss://) 在建立連接時使用的 HTTP 升級握手請求受同源策略約束。但是一旦連接建立后續通過該連接進行的雙向數據傳輸不受同源策略限制。這意味著你可以通過一個 WebSocket 連接與任何源的服務器進行實時通信。不過服務器端仍然可以在握手階段通過檢查Origin頭來決定是否接受連接這是一種應用層的安全控制。4. 跨域實戰從開發到部署的完整鏈路理解了各種方案我們需要將其串聯到實際的工作流中。一個典型的前后端分離項目跨域處理會貫穿開發、測試、部署全流程。4.1 開發環境的最佳實踐在開發階段我們的核心訴求是高效、無阻塞地調試。推薦組合使用以下方案首選開發服務器代理配置 Vite/Webpack Dev Server 的代理。這是最干凈、最模擬生產環境的方式。前端代碼中直接使用相對路徑如/api/user或配置一個基礎 URL由開發服務器負責轉發到真正的后端地址。這樣做的好處是前端代碼無需關心環境差異與生產環境的調用方式保持一致。臨時禁用瀏覽器安全策略僅限本地這是一個極其不推薦但有時用于快速驗證的臨時方法。絕對不要將其作為解決方案更不要指導用戶這樣做。Chrome通過命令行啟動chrome.exe --disable-web-security --user-data-dirC:\TempChrome。這會關閉所有同源策略檢查非常危險僅用于臨時測試。瀏覽器插件存在一些允許臨時禁用 CORS 的插件同樣只應在完全可控的本地環境使用。重要警告禁用瀏覽器安全策略會讓你暴露在各種網絡攻擊風險下僅可作為最后手段的臨時測試且測試后應立即關閉。在任何正式開發、測試或生產指導中都不應提及此方法。后端開啟寬松 CORS用于開發讓后端同學在開發環境的代碼中配置允許來自本地前端開發服務器地址如http://localhost:3000的跨域請求。這需要后端配合是比代理更“正式”一點的開發環境方案。實操心得在團隊中將開發服務器的代理配置寫入項目文檔或README.md是新成員快速上手的關鍵一步。確保vite.config.js或webpack.config.js中的代理配置清晰、準確。4.2 生產環境的架構設計生產環境中跨域問題主要通過后端和基礎設施層面解決前端代碼應保持“無感知”。標準方案后端配置 CORS這是最主流、最推薦的方式。后端服務在響應中設置精確的Access-Control-Allow-Origin等頭部。例如允許你的前端域名https://www.myapp.com和https://admin.myapp.com。切勿在生產環境使用*除非是完全公開的、無需憑證的 API如公開的天氣 API。架構方案API 網關 / 反向代理在微服務或復雜架構中通常會在前端和后端服務之間設立一個 API 網關如 Kong, Apigee或使用 Nginx 作為反向代理。所有前端請求都發往同一個域名網關域名由網關負責路由到內部各個微服務并在網關層面統一處理 CORS 策略、認證、限流等。這樣前端完全不用處理跨域后端各服務也無需單獨配置 CORS。CDN 與靜態資源對于圖片、字體、樣式等靜態資源的跨域可能會遇到字體文件的 CORS 問題font-face。通常的解決方案是在存放靜態資源的服務器如 OSS、S3、Nginx上配置 CORS 頭。使用 CDN 服務并在 CDN 配置中開啟 CORS 支持。對于字體文件除了 CORS 頭可能還需要設置Access-Control-Allow-Origin和正確的Content-Type。4.3 文件上傳與跨域的特殊處理文件上傳是一個常見的跨域難點因為通常涉及multipart/form-data格式和可能的大文件傳輸。方案一通過表單直接提交到目標域名。這是最傳統的方式表單的action直接指向目標服務器表單提交本身不受同源策略限制。但這種方式用戶體驗差無法在前端做預覽、進度提示等。方案二前端直傳 OSS推薦對于上傳到云存儲如阿里云 OSS、AWS S3的場景最佳實踐是前端直接從瀏覽器上傳到 OSS而不是經過自己的應用服務器中轉。流程通常是前端向自己的應用服務器申請一個臨時的、有時效性的上傳憑證STS Token 或預簽名 URL。前端使用這個憑證直接調用 OSS 的 SDK 或使用表單直傳 API 將文件上傳到 OSS。OSS 服務需要配置允許前端頁面所在域名的 CORS。在 OSS 控制臺可以配置詳細的 CORS 規則允許PUT、POST等方法以及必要的頭信息。// 以阿里云 OSS 瀏覽器直傳為例簡化 // 1. 從自己服務器獲取簽名和 policy const { signature, policy, ossHost, key } await getUploadTokenFromMyServer(); // 2. 構建表單數據 const formData new FormData(); formData.append(key, key); formData.append(policy, policy); formData.append(OSSAccessKeyId, your-temp-access-key-id); formData.append(signature, signature); formData.append(file, fileObject); // 文件對象 // 3. 直接 POST 到 OSS跨域請求OSS 已配置 CORS const response await fetch(ossHost, { method: POST, body: formData });方案三自己的服務器代理上傳。如果必須上傳到自己的服務器且服務器已正確配置 CORS允許Content-Type: multipart/form-data那么使用FormData配合fetch或axios上傳即可瀏覽器會自動處理預檢請求。5. 深度排查當 CORS 依然報錯時即使你認為已經正確配置了 CORS瀏覽器可能依然會拋出錯誤。以下是一個系統性的排查清單幫助你定位問題根源。5.1 預檢請求OPTIONS失敗這是最常見的問題之一。癥狀是 Network 面板中能看到一個OPTIONS請求并且它返回了非 2xx 狀態碼如 404, 405, 500或者響應頭中缺少必要的 CORS 頭。排查步驟檢查服務器是否響應 OPTIONS 方法很多后端框架的路由默認只配置了GET,POST,PUT,DELETE漏掉了OPTIONS。你需要確保你的路由或全局中間件能正確處理OPTIONS請求并返回正確的 CORS 頭。檢查Access-Control-Allow-Methods確保它包含了實際請求所使用的 HTTP 方法如PUT,DELETE。檢查Access-Control-Allow-Headers確保它包含了前端請求中出現的所有自定義頭如Authorization,X-Custom-Header。像Content-Type為application/json時也需要將其加入允許的頭部列表。檢查Access-Control-Max-Age如果設置了這個頭瀏覽器會緩存預檢結果。在調試時可以暫時將其設置為0或移除以確保每次請求都發送預檢方便看到最新改動。5.2 憑證Cookies與Access-Control-Allow-Origin沖突錯誤現象前端設置了credentials: ‘include‘但服務器響應頭Access-Control-Allow-Origin的值是通配符*。瀏覽器控制臺報錯The value of the ‘Access-Control-Allow-Origin‘ header in the response must not be the wildcard ‘*‘ when the request‘s credentials mode is ‘include‘.解決方案服務器必須返回一個明確的、具體的源如https://www.myapp.com而不能是*。同時響應頭中必須包含Access-Control-Allow-Credentials: true。5.3 響應頭未暴露給前端錯誤現象前端可以收到響應但無法通過response.headers.get(‘My-Header‘)讀取某些自定義響應頭。原因默認情況下瀏覽器只將簡單響應頭Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma暴露給前端 JavaScript。其他自定義頭如Authorization,X-Pagination-Total需要服務器通過Access-Control-Expose-Headers頭顯式暴露。解決方案在服務器響應頭中添加Access-Control-Expose-Headers: ‘Authorization, X-Pagination-Total‘。5.4 攜帶 Cookie 的請求Origin 檢查失敗錯誤現象請求攜帶了 Cookie但服務器檢查Origin頭后發現不在白名單內因此拒絕了請求。排查確保服務器端的 CORS 中間件邏輯正確。當使用credentials: ‘include‘時前端的fetch請求會始終攜帶Origin頭。服務器的邏輯應該是讀取req.headers.origin判斷其是否在允許的源列表中如果在則設置Access-Control-Allow-Origin為該具體的源值不能是*。5.5 使用工具進行網絡分析開發者工具 (Network Panel) 是你的最佳朋友打開Preserve log保留日志防止頁面跳轉請求被清除。找到出錯的請求點擊查看Headers標簽。仔細對比「Request Headers」和「Response Headers」。Request Headers查看Origin頭是否正確發送。查看Access-Control-Request-Method和Access-Control-Request-Headers僅在預檢請求中出現。Response Headers這是排查重點。逐一核對Access-Control-Allow-Origin,Access-Control-Allow-Methods,Access-Control-Allow-Headers,Access-Control-Allow-Credentials,Access-Control-Expose-Headers是否存在且值正確。查看Response標簽和Console標簽中的完整錯誤信息。跨域問題本質上是前后端協同的協議問題。前端需要知道如何發起合規的請求如設置credentials后端必須響應以正確的許可頭。掌握這套“握手”規則并善用瀏覽器開發者工具進行調試絕大多數跨域難題都能迎刃而解。記住安全是前提所有的解決方案都應在同源策略的框架內為合法的跨源通信開一扇窗而不是拆掉整面墻。