欢迎各位来到今天的研讨会。我是你们的讲师，一个在 React 代码世界里摸爬滚打多年的“老油条”。
今天我们不聊什么高深莫测的 Fiber 架构，也不去深究虚拟 DOM 的 Diff 算法。我们聊聊一个看似不起眼，实则像“家里装修水管爆裂”一样让人头疼的问题——事件监听。
特别是，我们要聊聊 React v17 之前和之后，那个关于“监听器到底该挂在哪里”的惊天大逆转。从 document 到 root，这不仅仅是换个地方挂横幅，这是物理隔离，是地盘意识，是 React 为了保护你那脆弱的代码不被第三方库“暴打”而竖起的一堵墙。
来，把你们的咖啡端好，我们开始。
第一部分：Document 时代的“群魔乱舞”
在 React v17 之前，整个 React 社区都沉浸在一种“单线程神话”的迷梦中。那时候，React 的事件处理机制非常简单粗暴：只要你的组件挂载了，我就去 document 上挂一个监听器。
是的，你没听错。不管你的应用只有几百行代码，还是像 Facebook 那样有几千个组件树，React 都会在浏览器最顶层那个 document 对象上，挂满各种各样的事件监听器。
想象一下，你在自家客厅（你的 React 应用）里开派对，大家玩得很开心。但是 React 的做法是：它把整个房子（浏览器）的大喇叭都抢过来，站在屋顶上喊：“只要有人点击，我就看一眼是不是我的派对客人在搞事。”
这种设计在当时看来似乎没什么问题，甚至很高效（事件委托嘛）。但是，随着互联网的发展，事情开始变得复杂了。
1. “邻居”的入侵
那时候，jQuery 是浏览器界的霸主。jQuery 也是非常喜欢在 document 上挂监听器的。
现在，假设你的页面里同时运行着 React 和 jQuery。React 在 document 上监听 click，jQuery 也在 document 上监听 click。
当用户点击页面时，document 会先触发 React 的监听器，然后触发 jQuery 的监听器。这听起来没问题？不，这简直是灾难。
更糟糕的是，React 的事件系统是基于“合成事件”的。它会拦截原生事件，做一些处理，然后冒泡。但是 jQuery 拦截了原生事件，React 想要冒泡到 document 时，发现路被堵住了。或者，React 处理完事件，想通过 e.stopPropagation() 阻止冒泡，结果 jQuery 根本不买账，事件照样往上传。
这就好比你家厨房着火了（React 事件触发），你想报警（阻止冒泡），结果隔壁邻居（jQuery）正拿着水枪在院子里滋水（监听 document），水花溅得到处都是，根本分不清哪是火哪是水。
2. 多个 React 应用的“相爱相杀”
在单页应用（SPA）成为主流之前，很多公司会在同一个页面上加载两个甚至更多的 React 应用。比如，一个电商网站，上面有个评论区是 React 写的，下面有个推荐流也是 React 写的。
在 v17 之前，这两个 React 应用都在 document 上监听 click。
这就好比你开了两个微信群，都在同一个群里说话。如果第一个群聊的人发了个红包，第二个群聊的人也能抢到。在 React 里，这意味着两个应用的 e.target 可能会互相干扰，e.currentTarget 的逻辑会变得极其混乱。你点一下评论区的按钮，推荐流里的组件可能莫名其妙地触发了 onClick。这就是典型的“跨应用污染”。
第二部分：从 Document 到 Root 的“物理隔离”
React 团队看着这些满屏的 Bug 和冲突，终于意识到：不能再在 Document 这个大杂烩里混日子了。我们需要隔离。
于是，React v17 做了一个极其大胆的决定：监听器不再挂在 document 上，而是挂在 React 组件树的“根节点”上。
这个根节点是什么？它通常是你 createRoot 传入的那个容器，可能是一个 <div>，可能是一个 <body>，甚至可能是一个 <span>。我们统称它为 rootContainer。
这个改动，就是所谓的物理隔离。
1. 什么是物理隔离？
想象一下，以前是“公共澡堂”模式（Document 监听）。大家都在一个大池子里洗澡，你搓背的时候会溅到别人的水，别人的水也会溅到你身上，谁也别想清净。
现在变成了“包间”模式（Root 监听）。
React 应用 A 在它的包间里装了一个监控探头（监听器）。React 应用 B 在它的包间里装了一个监控探头。这两个探头互不干扰。A 房间里的灯泡炸了（事件触发），B 房间里的灯泡完全不会受到影响。
这就是物理隔离的核心思想：作用域的边界。
第三部分：代码示例——见证奇迹的时刻
为了让你深刻理解这个变化，我们来看一段代码。
旧版本（v16 及以前）的噩梦
// 假设这是 React 内部的一些伪代码，为了方便理解
class ReactEventListener {
constructor() {
// React 在构造函数里，直接把监听器挂到了 document 上
document.addEventListener('click', this.handleTopLevelEvent, false);
}
// 处理顶层事件
handleTopLevelEvent(event) {
// 现在的麻烦在于，React 不知道这个事件到底属于哪个组件树
// 它必须遍历整个 document，看谁“捕获”到了这个事件
ReactDOMEventListener._handleTopLevel(event);
}
}
// 假设页面里有两个 React 应用
// App A
const rootA = ReactDOM.createRoot(document.getElementById('app-a'));
rootA.render(<App name="App A" />);
// App B
const rootB = ReactDOM.createRoot(document.getElementById('app-b'));
rootB.render(<App name="App B" />);在这种模式下，App A 和 App B 共享同一个 document 监听器。如果 App A 想阻止某个事件冒泡，它必须告诉 document 别传给 App B，但 document 并不关心谁是谁，它只知道有事件发生了。
新版本（v17+）的优雅
现在，让我们看看 v17+ 的代码是怎么做的。注意，这里的 API 也变了，我们不再用 render，而是用 createRoot。
// React v17+ 的核心变化
import { createRoot } from 'react-dom/client';
// 1. 定义组件
function Button({ onClick, children }) {
return (
<button onClick={onClick}>
{children}
</button>
);
}
function App() {
const handleClick = () => {
alert("App A 里的按钮被点了！这是我的地盘！");
};
// 2. 创建 Root
// 注意，createRoot 返回的 root 对象，是拥有“主权”的
const root = createRoot(document.getElementById('root'));
// 3. 渲染
root.render(
<div className="my-app">
<h1>这是 App A</h1>
<Button onClick={handleClick}>点击我</Button>
</div>
);
}
// ==========================================
// 如果在同一页面还有 App B 呢？
// ==========================================
function AppB() {
const handleClick = () => {
alert("App B 里的按钮被点了！这是我的地盘！互不打扰！");
};
// App B 也有自己的 Root
const rootB = createRoot(document.getElementById('app-b'));
rootB.render(
<div className="my-app">
<h1>这是 App B</h1>
<Button onClick={handleClick}>点击我</Button>
</div>
);
}
// AppB();看到了吗？ 虽然我们在页面上写了两个 createRoot，但 React 内部会为每一个 root 对象维护一个独立的事件监听器系统。
当你在 App A 的按钮上点击时，事件只会触发 App A 的逻辑。它绝对不会冒泡到 document 去找 App B，也不会影响到 App B 的内部状态。
这就是Root 级代理带来的安全感。
第四部分：技术细节——React 到底干了什么？
你可能会问：“React 是怎么做到的？难道它要在每个组件的根节点上挂监听器吗？那性能岂不是爆炸了？”
别担心，React 的工程师们还是很聪明的。他们依然使用了事件委托，但委托的目标变了。
1. 监听器的挂载位置
在 v17 中，当你调用 createRoot(container) 时，React 会找到 container 对应的 DOM 节点（比如一个 <div id="root">）。
然后，React 会在这个节点上挂载监听器。
// React 内部逻辑伪代码
function createRoot(container) {
const root = {
render(children) {
// 1. 渲染组件树
const fiberNode = reconcile(children);
// 2. 找到这个容器对应的真实 DOM 节点
const domNode = container;
// 3. 关键步骤：在这个 DOM 节点上挂载事件监听器
// 注意：不再是 document，而是 domNode
domNode.addEventListener('click', (event) => {
// 4. 事件进入 React 的处理流程
handleTopLevelEvent(event, fiberNode);
});
}
};
return root;
}2. 事件传播的路径变了
以前，事件路径是：Target -> React SyntheticEvent -> document -> window。
现在，事件路径是：Target -> React SyntheticEvent -> Root Container -> window。
这就好比以前你住在 101 室，出事了你要去一楼大厅（document）汇报，大厅的人可能把消息传给 102 室，也可能传给 103 室。现在你住在 101 室，出事了直接去 101 室的管家（Root 监听器）那里汇报，管家只管自家的事。
3. e.currentTarget 的稳定性
在旧版 React 中，如果你在多个层级都有监听器，e.currentTarget 可能会随着事件委托层级的变化而变化，导致代码难以预测。
在 v17 中，因为监听器直接挂在 Root 上，e.currentTarget 通常是稳定的，它始终指向那个包裹着整个 React 应用树的容器元素。
第五部分：为什么是“物理”隔离？——深度剖析
为什么我要反复强调“物理隔离”？因为这是理解这次重构的关键。
1. 解决第三方库的“霸凌”
React v17 之前，最著名的痛点就是与 jQuery 的冲突。jQuery 的 $(document).on('click', ...) 会拦截所有点击事件。React 必须从 jQuery 手里抢过控制权。
而 React v17+，监听器挂在 Root 上。如果页面上有一个 jQuery 监听器挂在 document 上，React 的监听器挂在 div#app 上，它们互不干扰。
- 点击
div#app内部：jQuery 监听器捕获不到（因为事件被 React 在div#app上拦截并处理了），React 处理完可能不冒泡，或者 React 处理完冒泡到了document，但 jQuery 已经在document上处理过了，这时候 React 的逻辑通常已经结束，不会造成混乱。 - 点击
div#app外部：jQuery 监听器捕获，React 不关心。
这种互不侵犯条约，让 React 和 jQuery 可以在同一个页面上和平共处。
2. 内存泄漏的减少（某种程度上）
虽然从技术上说，把监听器从 document 移到 div 并没有减少监听器的数量（可能还是 1 个），但它改变了监听器的生命周期绑定。
在旧版本中，React 在组件卸载时，需要去 document 上查找并移除特定的监听器。这涉及到复杂的查找逻辑（通过 ID、类型等）。如果逻辑写错，可能会导致内存泄漏。
在新版本中，监听器是绑定在具体的 DOM 节点上的。当这个 DOM 节点从 DOM 树中被移除时，React 自然也就知道该清理这个监听器了。这更像是一种“自然消亡”，更加符合直觉。
3. 浏览器原生 API 的升级
还有一个被很多人忽略的技术细节。在 v17 之前，React 为了兼容旧浏览器，使用了一个比较古老的 API：document.createEvent('Event')。这个 API 比较麻烦，需要手动初始化事件属性。
从 v17 开始，React 放弃了那个老旧的 API，直接使用现代浏览器都支持的 element.addEventListener。
为什么这跟“Root”有关？因为 addEventListener 是挂载在具体元素（Element）上的，而不是挂载在 document 上的。虽然 document 也是一个 Element，但 React 为了统一逻辑，选择将监听器挂载在真正的“根容器”上，这样就能顺理成章地使用 addEventListener，从而拥抱现代浏览器 API。
第六部分：实战场景——为什么这很重要？
让我们来看一个具体的实战场景，假设你在维护一个老旧的企业级系统。
这个系统里混杂着：
- 一个 5 年前写的 React 旧版应用（监听 document）。
- 一个正在开发的新版 React v18 应用（监听 Root）。
- 一个正在使用的 jQuery 插件（监听 document）。
场景： 你点击了新版 React 应用中的一个自定义的“删除”按钮。
-
v17 之前：
- jQuery 监听器先触发，判断：“这好像是删除操作，我执行一下我的动画吧。”（React 的按钮被 jQuery 搞晕了）。
- React 监听器触发，执行删除逻辑。
- jQuery 监听器再次触发，或者 React 监听器再次触发，导致页面状态不一致。
-
v17+：
- 新版 React 的监听器（挂在 Root 上）拦截了点击。
- React 执行删除逻辑，显示确认框。
- 事件处理结束，不再冒泡。
- jQuery 监听器（挂在 document 上）完全没感觉到这次点击，因为它只关心
document级别的事件，而 React 已经把事儿办完了。
这就是物理隔离带来的安全感。它把你的应用像一个个独立的气泡一样包裹起来，气泡之间互不渗透。
第七部分：总结——拥抱“房间文化”
React v17 的这次迁移，不仅仅是代码层面的调整，它是一种架构哲学的体现。
它告诉我们：不要把所有事情都堆在全局（Document），要学会建立边界（Root）。
- Document 是公共空间，是混乱的源头，是第三方库的游乐场。
- Root 是私有空间，是你的代码的领地，是你掌控节奏的地方。
通过将监听器从 Document 迁移到 Root，React 实现了真正意义上的事件代理隔离。它让 React 应用变得更加健壮、更加独立，也让开发者在与第三方库共存时，少了很多“排雷”的烦恼。
所以，当你下次在 createRoot 的回调里写代码时，请记住：你不再是站在空旷的广场上，你现在是站在自家的客厅里。这里的一切，都由你说了算。
好了，今天的讲座就到这里。希望大家在未来的开发中，都能给自己的代码建起一堵“Root”墙，别让外界的喧嚣干扰了你的逻辑。下课！