先说一下，这绝对不是一个安全的选择！
而且，只适合在开发过程中使用
好了，但是在开发过程中难免会请求到跨域的资源，可能是个测试数据，可能是个接口，这是因为浏览器的同源策略阻止了你的请求结果
同源策略是一个重要的安全策略，它用于限制一个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 登录状态啥的完全可能泄露给别人了。
