后记
文章发出后，争议比较大，评论数比点赞数量都高，好惭愧啊。😟
从评论上看，对于可选链的看法，大多声音是能加就加，多加总比少加好，原因就是不想背锅，不想上线后JS动不动就崩了，无论根本原因是不是前端开发没加判断导致的，第一责任人就会找到你，有的甚至会被上级追责，问题就更严重了，而且很难解释清楚；另一方面就是为了赶工期，可选链的其中一个优点就是简单，提高开发效率。
大家说的都对，前端程序员都一定吃过不少亏，多加总比少加好。
不过，也有的评论可能没get到我的点，我文里语言表达的也有问题，我就从两方面浅浅的扩展下我的看法：
滥用（图省事）
单从滥用的方面看（不是指后端返回数据处理情况），从我这边项目来看，确实有很多开发是无脑加的，甚至有工作几年的老开发。有些很明显不可能是空值的，一律都加。我感觉有些开发可能知道有些属性没必要判断非空，但是图省事，也不用费脑子，加了也不碍事，也就觉得无所谓了。
我承认多少有点 "强迫症" 了。但是从这个特性角度看，可选链这个新特性，增加了“滥用”的便利性，判断非空更容易了，不用写if或者三元运算符这种费劲的代码，只需加个问号就行了，也就让这种现象更加泛滥了，也不是说这个特性不好哈，凡事都有两面性。
隐式忽略异常？（我不要背锅）
比如 在后端api返回数据的处理、或别的组件或页面传过来的参数 之类的场景。这种本质上，其实是应不应该加非空判断的问题，并不是只针对可选链，只是说可选链的特性放大了这种问题。
我觉得对于这种情况问题，得分两种情况：
- 一种是返回值是不是空值不影响业务逻辑，比如某个流程api返回值是个可选项，可能是空值。
这种情况可以判断非空，我觉得完全没问题，因为它可能是空值嘛。比如api可能返回null或者空的数组，我加个非空判断转换为空的数组再进行处理。
再一个原因就是评论里普遍提到的："信不过"后端开发，所以加了非空验证。
- 另一种是情况相反，这个api返回值是个必填项，意思如果返回了空值则会影响后续的业务流程，这个时候如果也加上非空判断，那就会继续走后面的业务流程，就可能会导致页面某个field没值，或者某个操作没反应，再或者导致后续api产生脏数据，这就是我文里说的情况。
如果不加非空判断，这种问题就会被提前暴露出来，在调用api返回的时候就会js抛错，白屏，提早发现问题。不会隐式忽略异常，这就是文中说的观点。
就是说，无论是否判断非空都会产生bug，都会有线上bug，只是bug现象不一样、产生时间先后的区别了。虽然看似是前台没有判断非空，js抛错的原因导致白屏，其实很可能是后端api逻辑问题，导致了空数据的返回。
但是大部分开发还是会选择加上非空判断，页面随便就白屏很容易被"扣锅"，甚至会被追责，线上更严重，就是评论里大部分网友担心的问。分析问题慢？导致后续流程数据出问题？都跟我没关系，数据问题先找后端开发，别找我。
对了，还一方面考虑，就是从客户体验上看，这种问题的表现形式，最好是以一个弹框提示error，或者页面某些数据没达到预期这种方式表现出来。比如点个按钮抛错了、或者某个table数据显示不对、没值这种。而不是点点就白屏了，或者点点就没反应这种现象，这种情况会严重影响用户体验，降低客户信任度，甚至导致客户不开心。🙁
所以综上，加吧，能加就加吧，你们说的都对。🙂
