大家好！我是你们的 React 架构师，今天咱们不聊虚的，咱们来聊聊一个曾经让无数微前端开发者深夜脱发，后来又让他们重获新生的技术变革——React 事件委托的迁徙。
你们有没有想过，为什么 React 在 v16 的时候像个独狼一样，把所有的耳朵（事件监听器）都挂在 document 身上？而在 v17 的时候，它突然变得“彬彬有礼”，把监听器挂在了具体的 Root 节点上？
这不仅仅是代码的改动，这是一场关于“领地”和“噪音”的战争。特别是在微前端这个充满了各种“邻居”的公寓大楼里，这个改动简直就是从“全员混住”变成了“分层管理”。
来，搬好小板凳，我们开始这场技术探险。
第一部分：v16 的“独狼”与 document 的喧嚣
在 React 16 以及更早的版本里，事件委托的策略是这样的：React 是一个拥有强迫症的“大管家”，它不相信任何一个具体的 DOM 节点，它只相信 document。
当你的应用启动时，React 会跑到 document 身上，挂上几千个甚至几万个 addEventListener。不管你是在一个 <button> 上点击，还是在 <div> 上滚动，所有的原生事件都会冒泡到 document。然后，React 的“魔法手”会在 document 上拦截这些事件，通过它精心设计的“事件合成系统”进行分发，最后找到你写的那个 onClick，执行你的函数。
这听起来很完美，对吧？就像是在全国都装了一个总台，不管你在哪个省，信号都能收到。但是，这种“独狼”模式有一个致命的缺陷：它太吵了，而且容易打架。
想象一下，你的应用是一个人，你在这个人身上挂了所有的监听器。现在，你的应用变成了一个微前端架构，你引入了另一个库，比如 jQuery，或者另一个 React 应用，它们也都在 document 上挂监听器。
这就好比在一个房间里，有两个人同时在对着同一个麦克风说话。一个人说“你好”，另一个人说“再见”。结果呢？麦克风坏了，或者两个人都听不见对方。在技术术语里，这叫事件监听器的堆叠和冲突。
在 v16 时代，微前端场景下的问题开始显现。如果你的主应用和子应用都用了 React，它们都试图在 document 上控制全局事件流，那么当你点击子应用的一个按钮时，主应用可能会误判，或者子应用的事件根本传不到你的组件里。这就是所谓的“幽灵事件”和“事件丢失”。
第二部分：微前端——混乱的公寓大楼
为了理解为什么要移到 Root，我们必须先理解微前端的架构。微前端的核心思想是“积木化”，把一个大应用拆成几个小应用，分别开发，分别部署，最后拼在一起。
这就好比一个巨大的公寓大楼。以前 v16 的做法，是让整个大楼的管理员（document）站在大门口大喊，告诉谁谁谁家有人要出门了。
但在微前端里，这个大楼里住了很多户人家（不同的应用）。如果所有住户都去找同一个门口的管理员喊话，那门口早就堵死了。
举个具体的例子：
假设你有一个主应用，它依赖 react-router-dom。当你点击一个链接时，react-router 会拦截这个事件，阻止页面的跳转。这是 v16 的标准行为。
现在，你引入了一个微前端子应用，它里面也有自己的 react-router，或者它使用了 jQuery 来处理点击事件。
在 v16 中，主应用的 React 事件监听器在 document 上。子应用的 React 事件监听器也在 document 上。当你在子应用的一个按钮上点击时，事件会冒泡到 document。主应用的监听器先捕获到这个事件，于是它心想：“哦，这是一个链接点击，我要去控制路由了！”然后它调用了 e.stopPropagation()。
悲剧发生了。 因为在 v16 中，e.stopPropagation() 会停止整个原生事件流的传播。这意味着子应用的 React 根本不知道发生了点击事件，子应用里的组件根本不会渲染。你的微前端应用，瞬间就“哑火”了。
这就是为什么 v16 在微前端场景下是个噩梦。它无法处理多个 React 应用共享同一个 document 的情况。
第三部分：v17 的“分区”策略——回归 Root
React 团队意识到，这个“独狼”策略在微前端时代是行不通的。于是，在 v17 中，他们做了一个重大的架构调整：取消在 document 上的全局事件委托，改为在每个 React Root 节点上直接监听事件。
这意味着，如果你在一个 ID 为 root 的 div 上渲染你的应用，React 就只会在 #root 这个 div 上挂监听器。如果你的微前端子应用挂载在 #sub-root 上，React 就只会在 #sub-root 上挂监听器。
这就好比把那个站在大门口喊话的管理员，变成了每个楼层（每个应用）自己的专属管家。大家在自己的楼层里互相沟通，互不干扰。
代码示例：从 Document 到 Root
让我们看看代码上的区别。
v16 的做法（思维模型）：
// React 内部逻辑（伪代码）
document.addEventListener('click', function(event) {
// React 合成事件系统在这里工作
// 它遍历 DOM 树，找到对应的组件
// 执行 onClick
});v17 的做法（实际代码）：
// 我们调用 hydrate 或 render，传入一个 container
const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
<App />
);
// React 内部逻辑（伪代码）
const container = document.getElementById('root');
container.addEventListener('click', function(event) {
// React 合成事件系统在这里工作
// 它只在这个 container 内部查找对应的组件
// 执行 onClick
});看，是不是简单多了？React 不再是“满世界找你”，而是“就在你家门口等你”。
第四部分：为什么这能解决微前端问题？
现在，让我们回到微前端场景。
场景： 主应用（React A）和子应用（React B）并存。
v16 问题重现：
- 用户点击子应用 B 的按钮。
- 原生事件冒泡到
document。 - React A 在
document上的监听器捕获到事件。 - React A 执行
e.stopPropagation()。 - React B 没戏了。
v17 解决方案：
- 用户点击子应用 B 的按钮。
- 原生事件冒泡到
#sub-root。 - React B 在
#sub-root上的监听器捕获到事件。 - React B 执行
e.stopPropagation()。 - 关键点： 这个
stopPropagation只停止了#sub-root内部的事件传播。它不会影响主应用 A 的监听器，因为主应用 A 的监听器挂载在#root上，而不是#sub-root上。
通过这种“物理隔离”，React 17 实现了不同应用之间的事件系统互不干扰。这就像给每个微前端应用都穿上了一层防弹衣，外面的子弹（事件）打不进来，里面的子弹也打不出去。
第五部分：事件捕获的“时空穿越”——这是个大坑！
虽然把监听器移到了 Root 解决了冲突，但这也带来了一些副作用，最著名的就是事件捕获逻辑的倒置。
在 React 16 中，事件处理的顺序是这样的：
- 捕获阶段： 事件从
document向下传播。 - React 处理： React 在捕获阶段处理
onClick（实际上是onCapture）。 - 冒泡阶段： 事件从子元素向上传播到
document。 - React 处理： React 在冒泡阶段处理
onClick。
而在 React 17 中，因为监听器挂在了 Root 上，事件处理的顺序发生了变化：
- 捕获阶段： 事件从
#root向下传播。 - React 处理： React 在捕获阶段处理
onClick（实际上是onCapture）。 - 冒泡阶段： 事件从子元素向上传播到
#root。 - React 处理： React 在冒泡阶段处理
onClick。
看起来一样？别急，这有个陷阱。在 v16 中，onClickCapture 是在原生事件捕获阶段处理的。而在 v17 中，onClickCapture 是在React 事件捕获阶段处理的。
为什么这很重要？
因为 React 的事件系统有自己的“冒泡”。即使你在 React 17 的 onClickCapture 里调用了 e.stopPropagation()，原生事件仍然会继续传播。
这在微前端场景下尤其容易出问题。
代码示例：stopPropagation 的坑
假设你有两个应用，主应用和子应用。
// 主应用组件
function Parent() {
console.log('Parent onClick');
return (
<div onClick={() => console.log('Parent onClick Handler')}>
<Child />
</div>
);
}
// 子应用组件
function Child() {
console.log('Child onClickCapture');
return (
// v16 和 v17 的行为差异就在这里
<div onClickCapture={() => {
console.log('Child onClickCapture Handler');
// v16: 这行代码会阻止原生事件继续冒泡到 document
// v17: 这行代码只会阻止 React 内部的事件冒泡，原生事件继续冒泡
// e.stopPropagation();
}}>
Click Me
</div>
);
}v16 的行为：
- 点击 “Click Me”。
- 原生事件捕获：无（因为 div 通常是冒泡）。
- 原生事件冒泡：
Child->Parent。 - React 在
document拦截。 - React 处理
onClickCapture（实际上是捕获阶段逻辑）。 - 调用
stopPropagation()。 - 结果： 原生事件停止。主应用的
Parent onClick不会执行。
v17 的行为：
- 点击 “Click Me”。
- 原生事件冒泡：
Child->Parent。 - React 在
#root拦截。 - React 处理
onClickCapture。 - 调用
stopPropagation()。 - 关键点： React 的事件冒泡停止了，但是原生事件还在继续传播！它会继续冒泡到
#root的父元素，甚至document。 - 结果： 主应用的
Parent onClick依然会执行。
这就导致了微前端场景下的一个诡异现象：你在子应用里阻止了事件，但主应用还是收到了通知。这在某些严格的权限控制或路由守卫场景下，会导致逻辑错误。
第六部分：e.persist() 的消亡与原生事件的真相
v16 还有一个很臭名昭著的 API：e.persist()。
在 v16 中，React 使用“事件池”来优化性能。当你调用 e.persist() 时，你告诉 React：“嘿，别把这个事件对象回收了，我要在异步回调里用。”否则，如果你在 setTimeout 里访问 e.target，你可能会得到一个被重置的对象（比如 target 变成了 window）。
但在 v17 中，React 移除了事件池。因为事件监听器现在挂在 Root 上，而不是 document 上，React 不再需要担心全局事件池的竞争问题。这使得事件对象在 React 内部被视作“持久的”。
所以，在 v17 中，e.persist() 不再存在了。 如果你在代码里还留着它，编译器会报错。
代码示例：e.persist() 的迁移
v16 代码：
function handleClick(e) {
e.persist(); // 必须调用！否则 setTimeout 里拿不到 target
setTimeout(() => {
console.log(e.target); // v16: 可用
}, 100);
}v17 代码：
function handleClick(e) {
// v17: 不需要 persist() 了
setTimeout(() => {
console.log(e.target); // v17: 可用
}, 100);
}这虽然是个小改动，但意味着你的代码库里可能有几千个 e.persist() 需要被清理。这也是 v17 的一个“破坏性变更”。
第七部分：深入微前端——如何优雅地处理 v17 的变化
既然 v17 的 Root 委托策略如此强大，为什么有些老项目还在用 v16？因为迁移成本。
如果你正在开发或维护一个微前端项目，你需要特别注意以下几点：
1. 原生事件与 React 事件的隔离
在 v17 之前，你可以通过监听 document 上的原生事件来处理全局逻辑。现在，你不能再依赖 document 了。你必须使用 useEffect 在你的 Root 组件上监听原生事件。
function App() {
useEffect(() => {
// 必须在 Root 上监听，而不是 document
const handleGlobalClick = (e) => {
console.log('Global click', e.target);
};
const rootElement = document.getElementById('root');
rootElement.addEventListener('click', handleGlobalClick);
return () => {
rootElement.removeEventListener('click', handleGlobalClick);
};
}, []);
return <div>My App</div>;
}2. 第三方库的兼容性
如果你的微前端里集成了 jQuery 或其他依赖全局事件监听器的库，v17 的变化可能会影响它们。但好消息是，这些库通常监听的是具体的 DOM 节点，所以影响不大。真正受影响的是那些试图在 document 上做全局拦截的库。
3. 事件委托的边界
在微前端中，你可能需要处理跨 Root 的事件通信。比如，子应用想通知主应用发生了什么。你不能再用 document 事件了。你需要使用一种跨应用通信的机制，比如 window 的 postMessage，或者一个自定义的事件总线（Event Bus）。
// 子应用
document.getElementById('sub-root').dispatchEvent(new CustomEvent('app-sent-message', { detail: 'Hello' }));
// 主应用
window.addEventListener('app-sent-message', (e) => {
console.log(e.detail);
});第八部分：React 事件系统的底层逻辑——为什么 Root 更好？
为了更深刻地理解，我们得聊聊 React 事件系统的底层。
React 的事件系统是一个双层架构：
- 原生层： 浏览器提供的
addEventListener。 - 合成层： React 提供的
SyntheticEvent。
在 v16 中，React 在 document 上监听所有事件。当事件发生时，React 会模拟事件在 DOM 树中的传播路径（冒泡或捕获），并找到对应的组件。这个模拟过程在 React 内部维护了一个虚拟的 DOM 树。
在 v17 中，React 在 Root 上监听事件。当事件发生时，React 依然会模拟传播路径，但这个路径只限于当前的 React Root 内部。
这种改变，让 React 的渲染性能有了微小的提升。因为监听器的数量减少了（每个 Root 一个，而不是每个 Document 一个），而且事件冒泡的层级也变少了。
此外，v17 还引入了一个概念叫做 “事件目标” 的变更。
在 v16 中，事件目标始终是触发事件的 DOM 节点。
在 v17 中，为了更好的微前端隔离，React 修改了事件目标的设置。在 React 17 的事件系统中，事件目标始终是触发事件的那个原生 DOM 节点，但 React 会通过某种机制确保这个节点属于当前的 React Root。
第九部分：实战演练——微前端架构中的事件委托迁移
假设我们有一个基于 qiankun 的微前端架构。
旧架构（v16）：
// main.js (主应用)
// 主应用挂载在 #app
document.addEventListener('click', (e) => {
// 主应用逻辑
});
// micro-app1.js (子应用)
// 子应用挂载在 #micro1
document.addEventListener('click', (e) => {
// 子应用逻辑
});
// 冲突！新架构（v17）：
// main.js (主应用)
const root = ReactDOM.createRoot(document.getElementById('app'));
root.render(<MainApp />);
// micro-app1.js (子应用)
const microRoot = ReactDOM.createRoot(document.getElementById('micro1'));
microRoot.render(<MicroApp1 />);
// 没有冲突！第十部分：总结——从混乱到秩序
React 17 将事件委托从 document 移至 Root，不仅仅是一个技术细节的调整，它是对现代 Web 开发，特别是微前端架构的一种适应。
它解决了以下核心问题：
- 命名空间隔离： 不同的 React 应用可以在同一个页面上和平共处，互不干扰事件流。
- 微前端兼容性： 消除了
e.stopPropagation()在不同应用间互相影响的问题（虽然引入了原生事件继续传播的新问题，但这是可控的）。 - 性能优化： 减少了全局监听器的数量，降低了内存占用。
当然，这种改变也带来了挑战，比如 e.persist() 的移除，以及原生事件处理的边界问题。但作为一个资深开发者，拥抱变化，理解其背后的逻辑，是我们在技术浪潮中生存的唯一法则。
所以，下次当你看到你的 React 应用从 v16 升级到 v17，或者你在微前端里配置新应用时，请记住：那个在 document 上大喊大叫的“独狼”不见了，取而代之的，是一个在各自 Root 上尽职尽责的“管家”。这就是 React 事件委托的演进，这就是微前端的未来。
好了，今天的讲座就到这里。希望你们以后再写代码时，能想起今天讲的这些“噪音”和“领地”的故事。如果有任何关于事件委托的疑问，随时来找我，咱们继续聊！