共计 3193 个字符，预计需要花费 8 分钟才能阅读完成。
写在前面
前段时间，我写过一篇文章前端开发中的 Error 以及异常捕获。在文章中，我提到了这个问题：
经过不断探索 (不想再喷自己了)，我找到了原因。下面一一道来。本文主要讲解自己找问题原因的思路，如果想看结论和总结，请直接跳到文末。
问题复现
我是在自己以前的项目中测试 addEventListener 的重写的。这里直接上精简后的问题代码：
import React from ‘react’;
import ReactDOM from ‘react-dom’;
const nativeAddEventListener = EventTarget.prototype.addEventListener;
EventTarget.prototype.addEventListener = function (type, func, options) {
const wrappedFunc = function (…args) {
try {
return func.apply(this, args);
} catch (e) {
const errorObj = {
error_msg: e.message || ”,
error_stack: e.stack || (e.error && e.error.
error_native: e
};
}
}
return self.nativeAddEventListener.call(this, type, wrappedFunc, options);
};
const App = function() {
return <div>11111</div>
};
ReactDOM.render(<App/>, document.body);
运行这段代码，浏览器上一片空白，但是却没有任何报错。我一脸懵逼。
问题初探索
删掉那一点重写 addEventListener 的代码后，表现符合预期了。应该是重写那儿的问题。但是仔细看了过后，那段代码并没有什么问题。并且这段代码我在其他地方也试过，表现一直是正常的。是不是和 React 哪里冲突了？我使用的 React 版本是我搜索了 react-dom 源码中的 addEventListener 关键字，总共出现了四次。初步看了一下，并没有什么问题，只是注册了一些事件而已。没有具体分析这些代码的含义，我选择了先更换 React 的版本试一试，于是，我换成了 15.6.2 的版本。令人吃惊的是，表现符合预期了。难道真的和 React 的版本有关系? 在我的认知中，两个版本中最大的不同就是：React v16 采用了全新的 Fiber 架构，而我对 Fiber 的理解大概就是：重新设计了 react node 的数据结构，模拟实现了自己的任务堆栈，结合时间分片来进行任务的调度，从而更新整个系统。另外，React 有自己的一套任务系统，addEventListener 和任务也是紧密相关的，难道影响到了这个?
继续探索
我决定从 ReactDOM.render() 这个方法入手，调试一下 ReactDOM 的源代码。之前并没有研究过 React 的源码，压力有点大。调试了一翻之后，我并没有发现什么问题，并且已经有点懵逼了。我准备同时调试 react v15 和 react v16 的代码，看看有什么不同。为了方便，我将问题代码全部抽了出来，全部写到了一个 html 文件中，并且直接引用 React 的 cdn 地址。这个时候，我发现了一个神奇的问题：直接引用 cdn 地址后，不管 React 是什么版本，就算是 v16 版本，也不会出现之前问题，表现都是符合预期的。我更加懵逼了。
发现问题
静下心来仔细观察后，我发现了，我 cdn 引用的都是 react 的 production 版本，而我在项目中使用的 react 代码，却是 development 版本的，难道是 development 和 production 的 diff 代码，导致了上面的问题。于是我重新仔细看了一下 v16 的 development 的代码，找到了代码中一段长长的注释：
大意就是：在开发版本中，react 不会采用 try{}catch(){} 的方式来捕获错误，而是会把所有开发者定义的 callback 用一个叫做 invokeGuardedCallback 的函数包裹起来，然后使用一个假的 dom，监听、触发自定义事件来执行 invokeGuardedCallback，并且通过一个全局的错误捕捉函数来捕获错误。
在这段注释的下面，就是注释中提到的 invokeGuardedCallback 的代码。
我仔细研究了这个 invokeGuardedCallback 的代码，其核心就是：
function invokeGuardedCallback(name, func, context, a, b, c, d, e, f){
…
var fakeNode = document.createElement(‘react’);
var evt = document.createEvent(‘Event’);
var evtType = ‘react-‘ + (name ? name : ‘invokeguardedcallback’);
var callCallback = function(){
…
fakeNode.removeEventListener(evtType, callCallback, false); // 这里很重要！！！
…
func.apply(context, funcArgs); // 这里是真正执行 react 中的逻辑代码
}
fakeNode.addEventListener(evtType, callCallback, false);
evt.initEvent(evtType, false, false);
fakeNode.dispatchEvent(evt);
…
}
react 将所有容易出错的函数，都用这个 invokeGuardedCallback 包了起来。每一次都重新造一个虚拟的 element，然后监听其自定义事件，并且立即触发这个自定义事件。调试了这个 invokeGuardedCallback 后，我发现在 react v16 中，发现很多函数被多次执行。为什么会多次执行呢? 终于，我找到了问题的原因：
我重写了 addEventListener, 在函数外包了一层 try{}catch(){}，返回的是一个新的函数，所以，最终注册在事件监听器上的，并不是我传入的那个函数。这个时候，调用 removeEventListener 时，无法移除我传入 addEventListener 的函数。
在 invokeGuardedCallback 中，removeEventListener 的逻辑相当于并没有生效。于是，在 Fiber 的调度中，某个函数被多次重复执行了，而被重复执行的函数并不是幂等的，问题便产生了。
问题的总结与思考
问题终于定位了，一句总结，就是：
重写了 addEventListener，却并没有考虑到与之对应的 removeEventListener，导致 removeEventListener 无法正常工作。
下面是一些思考：
一开始，如果我仔细看一下 react 源码中 addEventListener 周围的代码，或许能更早发现这个问题，就不用绕这么大一个圈了。
自己对于第三方库的 development 版本和 production 版本，并没有一个很强烈的认知、意识，以前上线的不少项目，线上竟然还是用的第三方库的 development 版本，这个毛病，一定得改掉。
分析问题的能力还很欠缺，不够敏感。考虑问题的全面性需要提高。
真的不要随便重写原生方法。。。
写在后面
在探索这个问题的过程中，我看到了 react 巧妙应用自定义事件来捕获错误。于是，我全面总结一下了 Web 中的事件系统，也算是对基础的巩固。由于篇幅已经不够了，这里就直接放文章链接吧：
谈一谈 web 中的事件谈一谈 web 中的事件
欢迎关注我的公众号: 符合预期的 CoyPan，这里只有干货，符合你的预期。
