在第三章节中，我们联调后台管理系统，因为后台服务接口没出来，所以我们使用的mock模拟数据来联调，这时候假如我们的正式后台接口出来了，我们的pro模板应当如何联调正式的后台管理系统呢？
关闭mock数据
正式联调后台接口的时候，我们要做的第一步就是关闭mock数据。
官方文档是这样介绍的。
下来我们根据官方的介绍走一遍流程看看是不是跟官方介绍一致。
- 我们打开根目录的 package.json文件。修改script。
"start": "cross-env MOCK=none UMI_ENV=dev umi dev",
在start命令中增加 MOCK=node
- 验证mock是否关闭。
修改完第一步后，我们保存下代码重启项目。然后再次请求 login 登录进行尝试。
会发现点击登录没反应了。
那也就是说，我们的mock数据已经被关闭了。
修改请求地址
下来我们则需要修改请求地址。
先来看一下官方对请求地址的说明
现在市面上所有的脚手架都提供了 proxy 的能力，底层基于 http-proxy-middleware, 这个包可以把所有符合正则匹配的请求转发到某个地址，这个配置可以将所有 /api 开头的请求转发到 http://www.example.org/ ,并且附带所有的参数，包括头信息和 cookie。有一点需要注意的是，在浏览器控制台里看到的仍然是 http://localhost:3000/api/xxx ,转化的步骤是在 node.js 中完成。
在pro中，是用proxy更加简单在config.ts中配置即可。我们打开根目录下的 src/proxy.ts 文件可与看到配置。
它的使用是在config.ts中进行使用的。默认接收一个参数，这个参数为当前项目的环境。默认是dev环境。
我们修改 config/proxy.ts文件的地址来进行尝试。
如上我修改了 dev的环境地址，为了安全起见，地址我隐藏了。大家可与修改这里为你们的正式请求地址。修改完成后，我们可与保存下代码再次进行尝试登录。
会发现，接口已经正式生效了。
至此，配置修改后台请求接口地址的工作就已完成了。但是细心的朋友发现了，当我点了登录后它没有变。还是在这个页面。
是的。这个还需要接下来配置几个地方。
也就是我们所说的运行时配置
运行时配置
getInitialState插件
打开app.ts中，我们可与看到一个方法 getInitialState 。
官方说这个插件叫做 初始化插件，它获取项目的初始化数据，例如（最新用户信息/菜单权限等）。它初始化的数据会缓存下来，我们可以在任何组件中使用useModel进行使用。
为此，我们可以在全局搜一下 useModel来查看它的使用方法。
项目的 getInitialState 方法
getInitialState 的使用
也就是说，我们在初始化的时候 getInitialState 的时候获取了最新用户信息，并且将它保存了下来，后续我们可以在任意组件中通过
const {initialState} = useModel('@initialState')
来进行获取这些信息并使用。
此处要注意的是， getInitialState 在请求的时候 会堵塞页面加载。所以接口若是返回慢，页面也也会一直被堵塞。
这时候官方又提供了一个新的 api initialStateConfig 用来解决此问题。
initialStateConfig 是 getInitialState 的补充配置， getInitialState 支持异步设置，在初始化没有完成之前会堵塞页面加载。这时候我们可以利用 initialStateConfig 这个方法来配置一个loading 代替空白页面。
项目中如下：
当我们配置完如上之后会发现，我们也就是说知道了该在哪里去跳转页面。也就是登陆完成后并且获取到用户信息的时候跳转。
我们来修改下代码。app.tsx 。我们增加了一个console.log 来代替页面跳转，然后我们保存下，进行验证。
当我们再次 登录 点击确定后会发现，页面没有变化？
这是为什么呢？我们查看下登录页面的代码。
原来是因为登录接口出的问题，登录接口判断的是 status == ‘ok’,而我们的接口返回的是
所以无法执行 initialState 这个useModel，从而获取用户信息。
我们按照官方文档来修改下接口的返回值，并统一一下。
【官方描述】
当后端接口不满足该规范的时候你需要通过该配置把后端接口数据转换为该格式，该配置只是用于错误处理，不会影响最终传递给页面的数据格式。
也就是说，我们的后台接口返回值与前端的定义不一样，所以我们需要配置一个config来进行修改返回值。
按照文档修改后如上，然后我们再次修改 登录接口的返回值判断
再次保存后查看页面是否返回正确。
好了，接口返回终于没问题了。那我们再看下获取用户信息是否正确。
额，报错了。原因是没有token。怎么回事呢？
其实这里大多数朋友都能想得到。每次在一个后台管理系统中，需要token的接口占据大多数，但是也有不需要token的接口，也就是登录，我们在登录的时候获取到了token，但是却没有保存下来，在其它接口请求的时候加入到请求头中，所以导致没有token无法请求。
所以我们需要根据官方配置，使用 请求前拦截来处理增加上token。
我们照着文档写一个
上述代码的意思就是，当登录成功后，我们会保存token到全局，然后在请求其它接口的时候，我们判断是否有token，有的话就拿出来，增加到请求头上。options 则是我们在全局api接口定义处的 options。
做完以上后我们保存查看
项目已经成功登录。
如果看到这里，你会以为这就配置结束了？
不还没有。就比如说，我们默认所有接口返回的都是 200. 那如果接口返回的不是200 呢？
我们需要在每个接口请求下都判断 status == 200 吗？
答案是否定的。
这时候就需要我们的最后一个请求配置。
响应后拦截
在网络请求响应的 .then 或 catch 处理前拦截处理，使用方法基本和 requestInterceptors 相同。
也就是说，我们在这里可以统一去处理接口返回的状态，就比如。200 我们就正常处理。非200 状态，我们需要定义弹出框、提示、或者是401 我们需要退到登录页。这里我们需要用到一个配置就是 responseInterceptors 。
来我们一起走一遍流程。
上述代码中，我拦截了接口响应。
首先判断接口状态是否是200，如果不是200 ，那就证明我的接口请求有问题。
有问题我们就抛出异常： 您的网络发生异常，无法连接服务器！
如果接口状态正常，那么这时候我们就继续需要判断，接口内部定义的状态码。
也就是说是后台给我们的接口状态码是不是200.上述只判断了非200 .如果全部正常则正常抛出到页面。
我们首先判断401与 501 没有权限的时候或者登录过期的时候，我们清除token，抛出提示：用户已过期，请重新登陆。并返回到登陆页面。
其它状态非200 非 401 非501 的我们统一认为接口有问题。将后台给我们的异常抛出即可。
到此。我们的项目已经能够具备正常功能，能够利用模拟数据开发，能够接入后台接口进行开发，能够引入国际化进行开发，能够新增页面配置路由。
已经具备了一个项目初始化的形态。伙伴们，你们的跟我的一致吗？
如果不一致就赶紧看看是否有所不一样的存在。
下一章节，我们将一起重整项目，去除不必要的东西，留下一个纯开发模板。
