基于 HTTP 请求拦截，快速解决跨域和代理 Mock

近几年，随着 Web 开发逐渐成熟，前后端分离的架构设计越来越被众多开发者认可，使得前端和后端可以专注各自的职能，降低沟通成本，提高开发效率。

在前后端分离的开发模式下，前端和后端工程师得以并行工作。当遇到前端界面展示需要的数据，而后端对应的接口还没有完成开发的情况时，需要一个数据源来保证前端工作的顺利进行。

今天这篇文章，我们会介绍几种常见的方法和其中存在的问题，并提出如何基于HTTP 请求拦截，快速解决跨域和代理 mock 问题的方案。

常见方法及问题

请求 mock 服务器

最常规的做法是维护一个提供静态数据的 mock 服务器（它提供的数据称为 mock 数据），前端请求 mock 服务器获取数据即可，但这种静态数据维护不便。

请求 AMP

更好的做法是有一个根据接口定义来自动生成数据的 mock 服务器，我们称为AMP（接口管理平台，API Manage Platform），前端请求该服务器获取数据。

在这种场景下，如果有些接口已经完成开发，前端需要手动修改代码去设置不同接口的请求地址。当接口数量较多时，这种方法会变得非常低效。因此， AMP 一般也会同时提供代理功能，也就是指前端仍请求 AMP，AMP 会根据接口完成情况来决定返回 mock 数据，还是将请求再次代理到真实的业务服务器获取数据后返回。

但是这种方案的问题在于当涉及到需要角色权限验证的接口时，登录输入用户信息后在浏览器中会缓存 cookie，当访问与登录时同域名的接口时，浏览器会自动携带 cookie，由服务器解析 cookie 并鉴权后获取对应权限的接口数据。前端一般是在本地启动服务器进行开发，当业务服务器的接口完成开发，这时再采用请求 AMP 的方法切换接口数据，就会出现跨域的情况。

由于浏览器的安全机制决定跨域访问时无法携带 cookie，并且无法通过代码读取 cookie，因此通过代码传递 cookie 跨域不可行，而现有的解决方案也不完美：

• 如果在 AMP 额外增加模拟登陆的功能，会因为所有接口的权限固定不变，无法适配一个接口对不同角色有不同权限而返回相应的数据；而且一旦鉴权的接口功能变更、失效等情况发