接口请求失败、接口中部分数据缺失、运营数据不符合预期… 当我们的应用发布上线后，就开始面临这些风险。
而一旦这些问题导致了 JavaScript 报错（如空指针异常），并且没有被有效地隔离，就有可能引发页面的白屏、无法交互等线上问题。
在双 11 准备期间，我们收集了过往一年前端相关的线上问题，在收集的 21 个案例中，竟有一半的问题都与「数据异常触发页面显示异常」这个原因有些相关。
如何将错误的影响隔离在一定范围内，显得尤为重要。
这篇文章就和大家一起来聊一聊我们尝试过的一些方案，及遇到的问题。
数据引发的最常见的问题就是空指针异常。
var result = a.b.c.d;
这样的代码如同地雷，一旦 a 是一个动态数据，那么问题一触即发。
封装一个 get 的方法来取值，当数据不存在时，返回 undefined，可以快速避免此类问题。
var result = get(a, 'b.c.d');
但如同我们期望大家在取值前，都先做判断一样，并不能保证所有人都这么用了，用不用全靠自觉。
if (a && a.b && a.b.c) {
var result = a.b.c.d;
}
所以，有了以下的一些方案：
对异步数据校验的想法是，在数据获取后、使用前，先做一遍schema校验，检测重要数据缺失、类型不对等异常情况。
与此方案对应的，我们在 fetch 的基础上封装了 fetch-checker注1 组件。
fetch-checker 强制要求用户在请求数据的同时，提供数据对应的 schema：
let schema = {
"rule": {
"type": "string",
},
"banner": {
"type": "object",
"required": true,
"default": {
"url": "https://item.taobao.com/item.htm?id=527331762117"
}
}
};这份 schema 需要描述：
- 每个字段的类型
- 字段是否 required
- 当 required 的字段缺失时，是否需要打底数据
fetch-checker 在拿到数据后，先做一层校验，如有需要的话，补上缺失的数据，然后再返回给调用者。这样，使用者拿到的数据就一定是符合预期的。
然而，这个方案面临的挑战是：
- 如何确保调用者提供了完整的 schema 描述。不想写 schema，完全可以提供一个粗略的 schema 描述，来通过校验。
- schema 如何精简。即不会对 bundle 大小造成太大影响，又能满足校验的功能。
受 babel 的启发，这个方案是对存在 NPE 隐患的代码，在编译阶段，将其转换成等价的安全代码。如下所示：
var a = {};
// input
var result = a.b.c;
// output
var result = (_object2 = (_object3 = a) == null ? null : _object3.b) == null ? null : _object2.c;当 a 为空对象时，执行编译后的代码会返回 null，从而避免因为代码抛错，阻断后续进程。
在 babel-plugin-safe-member-expression注2 这个 Babel 插件中，我们做了上述的尝试。目前，cake项目中，已经可以通过 enableSafeMemberExpression 这个配置，选择性的启用该功能。
这个方案相比来说接入成本较低，开发者无需对现有的代码做出调整，但同样存在挑战：
- 开发阶段问题不易暴露，明明应该报错的场景，却没有任何反馈。理想的状态是：开发调试阶段尽可能多的暴露问题，线上则尽可能的减少报错。
- 隐患的代码如何界定。目前所有的
a.b的调用方式都会按上述方案进行编译，虽然测试过程中还没有发现问题，但只处理有隐患的代码才更安全。
以 flow 为代表的静态校验工具，可以在一定程度上检测出 NPE 隐患。
type res = {
data ?: Object
}
let name = res.data.name;
// property `name`. Propery cannot be accessed on possibly undefined value如上面的代码所描述的，使用者需要首先理清自己的数据是否允许为空值，当 data 被允许为空值时，通过 flow 检测，data.name 类似这样调用便会被检测出错误。
然而，如何来推进所有的业务都接入静态校验，接入后，又如何保证开发者描述了所有的类型，却同样是个难点。
总结以上几种方案，各有优缺点，都还不能算做最理想的解决方案。
| 方案名称 | 优势 | 缺点 |
|---|---|---|
| 提前判断 | 实行简单 | 全靠自觉 |
| 异步数据校验 | 可确保所使用的数据是满足预期的 | schema 描述成本高 |
| 代码编译 | 接入成本低，易执行 | 开发阶段不易暴露问题 |
| 静态校验 | 对现有代码逻辑侵入少 | 落地成本高 |
对于业务来说，最愿意使用和有效的方案一定是：
- 能将线上问题隔离在一个小范围内，同时不影响开发调试阶段的问题暴露
- 能提前暴露出隐患
- 接入成本低，不需要大量修改现有业务代码