不得不承认，我们的代码存在很多的逻辑边界没处理到，但这 React 15 的技术栈中，他们对于用户来说影响是很小的，一般不会感知。

    在做技术升级评估的时候，显然我们是没有重视到 React 16 中的异常抛错给我们带来的影响。初次升级完上线，正常流程都是可以跑的通的，然而随之而来的是很多的“白屏”反馈。这时候已经来不及了，我们在技术实现中用了不少 React 16 的新功能，它给我们还是带来不少好处的。但设想一下，如果你是用户，访问到一个页面的时候给你的是一个白屏，心理会是如何想的。这是第一点。

    随后，我们在整个页面生命周期的最上层加以异常捕获，将用户引导到问题反馈那边。随之而来的是络绎不绝的“页面出错了”主题，开始着急 — 用户看到的是什么？用户看到的是完全不符合预期的界面，而且有“系统错误”这样的严重提示，他们此时又会想些什么？这是第二点。

    幸好，我们在反馈的获取到简单的堆栈信息，得到第一手的异常分析内容。简单地分析了下大部分的异常都集中在编辑器里面。此刻我又有点紧张起来。在编辑器里面？那么用户的目的很明确 — 编辑文档，你让他们跳到一个不知道什么鬼的错误页面？他们还会继续用你么？这是第三点。

    为什么一次技术栈的升级，会带来这么多的系统异常？

    在 React 16 中，如果一个组件在运行时遇到了错误，那么会往其父组件冒泡，直到被某一个父组件捕获。假如一直没有捕获，页面就会白屏。从技术的角度来说，就是一个再小的错误，都会导致整个页面崩塌掉，除非你去关心这个错误，去处理它。

    这样的一个技术迭代，导致我们代码中的小 Bug 被一下子放大起来。但需要记住：对于遇到程序错误的用户来说，他们可能比你还奔溃，他们没必要为你的“代码错误”买单，没必要协助你“排查问题”，也没时间浪费在实现这么差的前端界面中。技术在更新迭代的时候，需要为你的用户负责，为你的产品负责。

    谨记：以商业产品付费体验的心态做技术，而非让用户来为技术的问题买单。