先說一下，這絕對不是一個安全的選擇！
而且，只適合在開發過程中使用
好了，但是在開發過程中難免會請求到跨域的資源，可能是個測試數據，可能是個接口，這是因為瀏覽器的同源策略阻止了你的請求結果
同源策略是一個重要的安全策略，它用于限制一個origin的文檔或者它加載的腳本如何能與另一個源的資源進行交互。它能幫助阻隔惡意文檔，減少可能被攻擊的媒介。
同源的定義
如果兩個 URL 的 protocol、port (en-US) (如果有指定的話)和 host 都相同的話，則這兩個 URL 是同源。這個方案也被稱為“協議/主機/端口元組”，或者直接是 “元組”。（“元組” 是指一組項目構成的整體，雙重/三重/四重/五重/等的通用形式）。
這個方案的優點就是快，適合開發，加載一個chrome拓展插件去劫持ajax，利用background.js發送請求繞過同源策略。
項目地址：https://gitee.com/boboanzuiniubi/ext-xhr-proxy
先看看效果
實現的原理
在 background.js 里發送的請求是不會跨域的
加載了拓展插件，會有一段個 content_script 的 script 注入到你的頁面(content_script 與網站的js是隔離開的，他們共享的只有document，他相對安全)，這個 script 中包含一些 chrome 瀏覽器的 api，content_script 在這里利用瀏覽器的消息 api 作為網站與 background 間的消息接口。
content_script 還有一個另外的作用，是他用 document 注入了一個 script 標簽（這里稱為 inject_script )，注入的 inject_script 并沒有與網站隔離，它可以訪問你任何變量，這個項目就修改了 XMLHttpRequest 構造函數，使他返回一個 xhr 的代理，使所有對于xhr對象的操作（open/send...）都被 xhrProxy 攔截到了，實現了 ajax 劫持
當 xhrProxy 對象攔截到需要被代理的請求時，會通過 postMessage 向 content_script 發送消息 content_script 則會把消息轉發到 background.js 在 background 中創建一個 xhr 對象發送真正的請求。在 response 后，再通過 content_script 原路返回 postMessage 到活動頁面上 更新 xhrProxy 的狀態實現代理請求
總結
先感謝一下 小茗同學大佬的文章 少走彎路發家致富。
用 extention 處理跨域在開發過程中是十分省時間的，畢竟加載一個 chrome 插件比起一個代理服務要快得多。
不過也想給大家提醒，我能使用 chrome 插件劫持 ajax 請求，我就能把請求轉發給我自己的服務器，是很不安全的，并且 inject_script 就在往頁面注入 js ，當你使用一個非官方的插件時，你不清楚他到底做了什么，比如你在瀏覽 steam 時正好開著一個不知名插件，那么你的 steam 賬號 密碼 token 登錄狀態啥的完全可能泄露給別人了。
