详解Axios统一错误处理与后置

问题

在进行业务开发的时候，前后端会对接口的数据结构进行约定，若接口有异常，需要将异常信息展示给用户知晓。这个流程里，数据结构是确定的（事先约定），数据的处理逻辑是相同的（展示给用户），如果在业务代码代码中重复的catch(e) { 展示给用户 }，就非常的不优雅。本着Don't repeat myself（懒）的原则，需要对接口错误进行统一处理。

接下来，我会结合具体的业务场景，讲一讲我的解决方案。

业务场景

后端通过http状态标识接口状态，错误信息在response的data里 前端的处理逻辑是使用element-ui的Message展示错误信息 使用axios

axios可以通过拦截器，在业务代码处理响应之前对响应进行处理,类似于下面的流程

someAPI()  .then(interceptorsFn)  .then(业务逻辑)

所以，我们可以在interceptors对响应进行统一处理:

request.interceptors.response.use(  (response) => response.data,  (error) => {    // 针对特定的http状态码进行处理    if (error.response && error.response.status === 401) {      router.push({ name: 'ssoLogin' })      return new Promise(() => {}) // pending的promise，中止promise链    }    .....    const msg = error.response.data    Message.error(msg)    return Promise.reject(error.response)  })

如何进行特定的错误处理

不难看出，上面的方案有一个问题，如果有某个接口需要有业务代码来展示定制的错误信息（这个情况十分常见），如何处理？

naive方案1：业务代码使用其它的方式展示信息：例如Notify。
这个方案被我司产品痛骂，因为破坏了统一的错误信息展示，并且此时统一的错误信息是一个垃圾信息，没必要展示。

naive方案2：业务代码直接使用Message，顶掉统一的错误信息。
这个方案还是被产品大哥（dog）怼了，因为明显的用户体验不好，错误信息出现了闪烁。

帅气的解决方案3：业务代码决定是否隐藏统一错误提示
那么问题来了，由于是先走拦截器，再走业务代码，如何由业务代码决定是否隐藏统一错误提示呢？

我的办法是，将统一的错误提示使用setTimeout放到下一个loop执行，并通过一个变量标识是否要执行统一错误提示。

request.interceptors.response.use(  (response) => response.data,  (error) => {    ...    setTimeout(() => {      if (tag) {        Message.error(msg)      }    })  })

接下来，需要考虑的是，如何在业务代码里改变标识变量

naive方案1：一个全局的变量或者方法

这个方案非常的不靠谱，若在其它代码里改变了这个全局变量，就嗝屁，并且N个接口公用一个标识变量，只能是同一个状态。