前言
如今前端领域是MVVM框架的天下，组件库也层出不穷，但是，并没有一个知名的组件库提供ajax异常的成熟解决方案，所以今天我们就来研讨一下，如何尽量正确地处理异常。
ajax异常的分类
1. 有响应
从业务上简单说，凡是code不是200的，都是异常。这里code可以是HTTP状态码，也可以是响应体的code，就不细究了，反正本质没差别。然后，根据code的不同，又可以细分成401 403 404 500等等。
如果你的后端伙伴以HTTP状态码表示404，以响应体code表示其他错误，而且你又无法劝说他们，那么你应在axios的拦截器里把各种情况全考虑进去，比如：
const code = res.status === 200 ? (res.data.code || 200) : res.status;
2. 超时
超时很简单，axios也支持，设定超时阈值即可。超时跟无响应的区别是，超时意味着HTTP三次握手成功，但是得不到响应体，浏览器知道接口是存在的，但是响应体又在规定时间内没有拿到。无响应是根本无法HTTP握手，也就无法获知接口存在。
处理超时，通常做法是在拦截器里重新请求一遍，还是超时的话就视为服务器错误。
3. 无响应
得不到响应又分成2种，可能是网断了，也可能是服务器停机了。
苛刻地说，你应分辨这2种情况，并给出不同的提示，毕竟网断了，用户可以寻找别的联网方式，而服务器停机了就给个重连按钮，让用户有事没事的尝试重连一下。
关于解决方案，首先说，XHR对象无法区分到底断网还是服务器停机，axios对于2种情况都返回'Network Error'。在得到这个反馈之后，你接下来可以有这2种解决办法：
1. axios拦截器内GET一个宕机概率极低的网站的一张极小的图片
var img = new Image();
img.src = 'https://api.map.baidu.com/images/blank.gif?_t=' + Date.now();
img.onload = function () {
// 服务器宕机了
};
img.onerror = function () {
// 网断了
};
你可以将https://api.map.baidu.com/images/blank.gif改成其他服务器稳定且字节小的图片。或许你可以做一张几字节的图片，传到一个非常牛逼的CDN上。
2. axios拦截器内利用navigator.connection API
MDN手册：https://developer.mozilla.org/zh-CN/docs/Web/API/Navigator/connection
它不支持IE，就算你不在乎这一点，那么它是不是一定准呢？对于需要登录的VPN网络，它是否准呢？我也不知道，总体说，它真的不是最佳的方案。我推荐用方案1。
报错提示有几种？
很简单，分为3种：
- 容器内错误提示
- 容器隐藏
- 弹出提示，比如toast、modal、警告条等
通常，一个接口，只需要按照其中一种去处理即可，优先级就是上面书写顺序。
3种提示的使用场景分析
1. 容器内错误提示
容器内错误提示肯定是内容区的接口出错才会出现。
处理方式：
- 局部报错
局部报错比较容易理解，比如一个List的接口出错，那么，上策是应当给这个容器尽量撑高到有内容时的高度，然后居中给一个错误图标和错误描述。中策是不考虑有内容时候的高度，只让错误提示和错误描述撑起一定高度即可。都不算错。如果容器很小，比如就是一个3位数值，那么用一个-表示错误也可以。
- 页面整体报错
页面整体报错稍微复杂，比如一个左右结构的内容管理系统，前置接口有userInfo接口、全局字典接口、全局路由接口等，这些接口与众不同的地方在于它们是基础接口，它们出错的话，网站干脆就不能用，页面骨架也是错乱的，这种情况下可以有2种解决办法：一是跳转到专门的5xx报错页面，页面中央有错误图标、错误提示，以及“返回上一页”的按钮；二是用白板遮罩覆盖浏览器视口，居中放一个错误图标和错误文字以及“刷新页面”的按钮，本质是用一个fixed的遮罩压住浏览器全部面积。用哪种方案都可。所以你要做的是决定哪些接口属于全局报错，哪些接口属于局部报错，并做不同的处理。
报错内容：
根据ajax异常的分类，可能至少能分出3种：网络错误、服务器宕机、服务器错误。具体用什么图标和文字我就不多说了。
组件化：
容器内报错应尽量组件化。该放返回上一页或刷新按钮的，一定要放按钮。
排他性：
只要做了容器内报错，就不要做另外报错了。这也说明了一点，就是在axios拦截器里弹toast或者modal是愚蠢的方案，我在别的文章也提到过这种观点。不做容器内报错的情况，才应该考虑其他3种情况。
2. 容器隐藏
什么样的场景下使用容器隐藏？
比如页面有一个角落显示你的粉丝数、关注数、评论量……。如果有获取到数据，则让这个容器出现，没有的话，则容器就保持隐藏。这一类场景往往应用于非主要内容，比如侧边栏的小内容块。
由于这只适用于非主要内容，那么主要内容也会有它自己的报错，所以，你不必担心用户看不到“网络出错”这类错误提示。
3. 弹出提示，比如toast、modal（以及MessageBox，下文混称modal）、警告条等
先简单对比一下toast和modal。
很简单，toast就是轻提示，不需要手动关闭，modal就是重提示，需要手动关闭。采用哪个，只要站在用户角度思考问题就好了。比如有人说，异常应当用重提示。可以这么绝对化么？不可以。比如你在某个页面点赞，提示你“您已经点过赞了”，这用重提示吗？肯定toast就够了。同样的，成功提示一定用轻提示吗？比如提示“感谢参与，工作人员将在3~5个工作日内联系你”，这么长，能toast？能一闪而过？
什么接口适用弹出提示？简单说，只要跟UI显示不相干的，都最好是使用弹出提示。比如这几种场景：
| 出错场景 | 处理办法 |
|---|---|
| 上传数据时断网、服务器宕机、服务器错误，与UI无关 | modal |
| 上传数据时数据内容错误，也与UI无关 | toast或输入框下方提示 |
| 401错误，也就是登录态过期，也与UI无关 | modal或toast |
先说上传数据断网之类的错误，通常用modal，因为modal能够拦截用户动作，避免重复上传，而且，还能给用户足够的时间让用户看清楚出错原因，避免无谓的重试。
然后说数据内容错误，无论是表单提交，还是点个赞，错误提示一般用toast，毕竟用户可能只是不小心填错的，看一眼然后赶紧改正就好了。
最后说401错误，有2种做法，一是用modal，因为一般要强制用户转到登录页，但是转之前也得让用户看明白为什么要转，所以可以先modal提示，点击确定就跳转到登录页；二是用toast，但是需要先跳转，然后在登录页上提示toast“请先登录”。
警告条
警告条是可关闭的、永久生命的、又不妨碍用户继续操作的弹出组件，一般在页面顶部，或者在用户操作区域的附近。什么场景用警告条？
比如简书的MD编辑器，你只要输入，就会自动给服务器发送数据，频率很快，有时候因为网络或者服务器的问题，会出现保存失败的可能性，这时候简书就会在页面顶部出现一个比较长时间的警告条，告诉你保存失败，但你依然可以继续写，什么时候网络正常了，什么时候toast才会自动消失，当然你也可以手动关闭它。
总之，toast、modal、警告条究竟什么场合使用，要根据产品、业务具体而定，要注意优先使用容器内报错和容器隐藏。
