本地 Proxy 方案

在使用代理功能时，请先明确一下问题：

  • 所谓代理功能，是为了调试使用的，只能在本地开发时生效，构建或者发布之后无法使用
  • build-scripts 启动的代理服务只能代理当前服务端口的请求，比如 http://127.0.0.1:4444/api/foo，其他 ip 或者端口的请求都无法被代理，需要此功能的话请使用 Charles 或者 Nginx
  • 如果后端服务对接口做了登录鉴权，基本很难代理成功，因为请求发出的前端页面里没有 cookie 等用户信息

然后结合一些常见的跨域场景推荐一些方案：

  • 后端服务已部署（无论是测试环境还是生产环境），需要调试前端代码：直接访问后端服务的页面地址，然后将页面里加载的前端资源通过 chrome 插件 xswitch 代理成本地前端调试服务的资源，没有跨域问题，完全真实的数据，调试成本极低
  • 同一个人同时开发前端和后端代码，直接访问后端的服务地址比如 http://127.0.0.1:6001，这个页面里加载本地的前端资源，实现前后端代码的同时调试

如果不符合以上情况，那应该就属于下面的情况了，推荐通过代理功能解决：

为了代码维护性考虑前端请求后端接口时写的都是相对路径如 /api/getFoo.json，此时如果我们在本地通过访问http://127.0.0.1:4444 来调试页面，所有相对路径的 API 最终都会变成 http://127.0.0.1:4444/api/getFoo.json，因为我们的前端调试服务并没有提供这些接口，这些请求自然都会以 404 而结束，这时候就需要将这些请求代理到真正的服务地址：

操作方式

在 build.json 中配置 proxy 字段：

  1. {
  2.   "proxy": {
  3.       "/**": {
  4.       "enable": true,
  5.       "target": "http://127.0.0.1:6001"
  6.     }
  7.   }
  8. }

完整的配置项请参考 http-proxy-middleware。

匹配规则

  1.          foo://example.com:8042/over/there?name=ferret#nose
  2.          \_/   \______________/\_________/ \_________/ \__/
  3.           |           |            |            |        |
  4.        scheme     authority       path        query   fragment
  • / 匹配所有规则
  • /api 匹配 path 以 /api 开头的路径

代理示例

  1. axios({
  2.   url: '/api/proxy',
  3.   method: 'get',
  4. })
  5.   .then((response) => {})
  6.   .catch((err) => {});

请求发出后将会被代理到 http://127.0.0.1:6001/api/proxy，代理成功后可在 network 面板看到对应的信息：

本地 Proxy 方案 - 图1

注意事项

  • 代理之后我们可以通过相对路径的接口正常请求到后端服务，但是如果后端接口做了帐号登录鉴权之类的事情请求一样会失败，因为此时调试页面里并没有登录相关的 cookie 信息
  • 代理之后可以理解为请求是从服务端发出，因此绕过了浏览器的同源策略，一定程度可以解决跨域问题，但一样无法绕过上文提到的 cookie 鉴权等相关问题