瀏覽器這堵墻攔了3億開發者5年，CORS真解法藏在后端

2024年Stack Overflow調研顯示，67%的前端開發者每周至少遇到1次CORS報錯。這個數字背后有個荒誕事實：九成的人第一時間去改前端代碼，而真正的開關其實在后端服務器手里。

「被屏蔽」不是Bug，是瀏覽器的本職工作

CORS（跨域資源共享，Cross-Origin Resource Sharing）本質是瀏覽器內置的安全門衛。它依賴HTTP頭（header）決定是否放行——當前端代碼試圖從A域名請求B域名的數據時，瀏覽器會先問B："這人能進嗎？"

Same-Origin Policy（同源策略）是這道門的默認狀態。沒有服務器明確授權，fetch或XHR請求直接撞墻。很多開發者誤以為這是JavaScript代碼寫錯了，花幾小時調試語法，其實方向完全偏了。

印尼開發者Alifyazz在Medium專欄里打了個比方：這像是住酒店時刷不開房門，你反復檢查房卡芯片，卻沒發現前臺根本沒給你開通權限。

為什么前端改配置是彎路

瀏覽器彈出"Blocked by CORS policy"時，錯誤信息里那個刺眼的紅色警告，容易讓人產生"我的代碼臟了"的錯覺。但CORS不是前端能單方面修復的功能缺陷——它是服務器與瀏覽器之間的協議握手。

臨時繞過方案確實存在。本地開發時掛個Web代理，讓請求假裝從同源發出，能騙過瀏覽器的安全檢查。但這招到了生產環境直接失效，就像用測試環境的假門禁卡刷正式辦公樓的閘機。

更隱蔽的坑是Chrome插件或某些"一鍵解決CORS"的工具。它們強行關閉瀏覽器的安全策略，把開發機變成裸奔狀態。Alifyazz警告過：這相當于為了進門方便，直接把小區圍墻拆了。

后端開門的標準姿勢

根治方案只有一條：服務器返回Access-Control-Allow-Origin頭。值可以設為*（允許所有域名），或指定白名單如https://frontend-kita.com。

Node.js示例通常長這樣——在響應頭里追加一行，告訴瀏覽器"這個前端域名我認"。Nginx或Apache的配置同理，核心都是讓服務器主動報家門。

Alifyazz維護的CrootJS工具鏈做了層封裝。它把ES6模塊（module）的導入語法和fetch調用打包成按需加載的模式，前端代碼里import { getData } from './api.js'就能直接拿到跨域返回的數據——前提是后端已經點頭。

這套方案的關鍵細節在于type="module"的script標簽。傳統