场景

前端本地开发，接口代理，页面代理，文件代理

本地开发时可封装统一的request方法，针对接口请求统一加上/api前缀。针对一些特定场景如APP内嵌H5项目，通过Bridge传入的参数，或者获取参数的方法，每次请求都需附带则可以通过拦截器针对请求前的参数进行修改, 在此处也可针对特定地址的接口进行特定的调整。而返回值的错误处理，如非正常状态的HTTP Status错误处理，可在response中进行拦截，如会话失效返回的401捕捉并进行重定向到登陆页面。
跨域有多种解决方案，但是代理是其中较为简单且解决比较完善的方案。

本地开发使用的各种前端脚手架，基本支持Proxy的配置，结合上文request方法统一加上的/api前缀，可在Proxy中直接针对/api路径进行代理配置，changeOrigin并且target到指定的后端接口url。不同环境的baseUrl也就无需配置。开发时不同环境的后端接口可能会出现不同，可通过CROSS ENV注入环境变量，针对环境变量维护一份接口地址Map，如:

export const targetUrl = {
  dev: 'DEV_API_BASE_URL',
  test: 'TEST_API_BASE_URL',
  uat: 'UAT_API_BASE_URL',
}

2.针对可能出现的iframe嵌套进组件的需求，也可以单独部署到其他服务器，如专门的pdf预览用页面，iframe的跨域问题和pdf文件的跨域问题，都可以通过配置Proxy来解决，如设置前缀/viewer与/file代理到对应的页面服务器与OSS文件服务器。

注意，目前涉及到的代理都是本地开发时候的脚手架提供的代理能力，部署后将失效，需要在服务端配置代理，一般使用Nginx的反向代理能力。

3.部署。部署涉及到的代理与本地的Proxy基本一一对应，可参考如下Nginx反向代理配置。

location ^~/api/ {
  proxy_pass API_BASE_URL；
}

注意斜杠。实际上反向代理是屏蔽了服务端，拦截了前端项目的访问路径，通过本机Nginx代理到不同目标服务器，这一过程对客户端来说是无感知的。而正向代理则刚好相反，代理了客户端，服务端对不同客户端是无感知。