各位好，欢迎来到今天的“React 内部原理深度解剖”研讨会。我是你们的讲师，一个在 React 事件池子里摸爬滚打多年的老司机。
今天我们不聊组件生命周期，不聊 Hooks，也不聊 Redux。我们聊点更刺激的——React 事件系统的“鬼故事”。
具体来说，我们要讨论的是那个曾经让无数 React 初学者半夜惊醒、让资深工程师对着屏幕抓狂的神秘方法——e.persist()。特别是，我们要搞清楚，在 React 15 的那个旧时代，这个方法是如何像幽灵一样潜入你的代码，又是如何随着 React 16 的到来彻底销声匿迹的。
来，把你们的咖啡端起来。准备好了吗？我们开始。
第一部分：幽灵的起源——为什么 React 要搞个“事件池”？
首先，我们要回到那个“遥远的过去”。也就是 React 15 甚至更早的年代。
如果你是一个 React 老手，你可能还记得，在 React 16 引入 Fiber 架构之前，React 的核心渲染模型其实相当简单：它就是一个基于虚拟 DOM Diff 的调度器。
但问题来了。React 的事件处理，和原生 DOM 的事件处理，完全是两码事。
在原生 JS 里，当你点击一个按钮，浏览器会给你一个 MouseEvent 对象。这个对象就像一张纸条，上面写着：“我是鼠标点击，发生在 x=100, y=200，目标元素是 Button”。
React 做的事情很“鸡贼”。它不想给每个 DOM 元素都挂载监听器。如果页面上有一万个按钮，难道要给每个按钮都加一个 addEventListener 吗？那内存不要了？性能不要了？
于是，React 采用了一个极其聪明的策略：事件委托。
React 只会在最顶层的 document 或者 root 节点上挂载一个监听器。当你点击一个按钮时，浏览器会把事件冒泡到根节点。React 拿到这个事件后，会通过 e.target 找到真实的那个按钮，然后“伪造”一个属于那个按钮的事件对象（也就是合成事件 SyntheticEvent），传递给你的处理函数。
这就是 React 事件系统的核心。
但是，这里有个巨大的性能陷阱。每次点击，都要创建一个新的对象吗？
在 JavaScript 的世界里，对象创建和销毁（垃圾回收 GC）是有成本的。如果用户疯狂点击，每秒点击 60 次，那岂不是每秒要创建 60 个合成事件对象？虽然现代 JS 引擎优化得很好，但在 React 那个年代，为了极致的性能，React 团队引入了一个极其激进的设计：对象池。
对象池是什么？简单说，就是“借了还”。
想象一下，你手里有个垃圾桶（池子），里面放满了刚用过的鼠标事件对象。当你需要一个新的 MouseEvent 时，你不扔掉旧的，也不创建新的，而是直接从垃圾桶里抓一个出来，把里面的属性（比如 target）稍微擦一擦，换个新的值，然后把这个“擦干净”的对象扔给你的处理函数。
这就叫对象池。它的核心思想是：重用。
在 React 15 中，这个池子是真实存在的。当你调用 e.stopPropagation() 或者 e.preventDefault() 后，React 并没有立即销毁这个对象，而是把它放回池子里，等待下一次事件发生时被再次复用。
这本来是个为了省内存的神器，结果却引出了那个著名的“幽灵事件” Bug。
第二部分：幽灵现身——setTimeout 里的 undefined
让我们来模拟一个经典的面试题场景。假设你正在开发一个购物车组件。
function ShoppingCart() {
const [message, setMessage] = useState("");
const handleCheckout = (e) => {
// 1. 我们需要获取点击的元素 ID，以便发送给后端
const targetId = e.target.id;
console.log("点击的目标 ID:", targetId); // 正常打印
// 2. 模拟一个异步操作，比如发起网络请求
setTimeout(() => {
// 3. 在回调里，我们再次尝试访问 e.target
// 注意：这里的 e 是闭包里的那个合成事件对象
console.log("异步回调中的目标 ID:", e.target.id);
setMessage(`正在处理 ${targetId} 的订单...`);
}, 1000);
};
return (
<button id="checkout-btn" onClick={handleCheckout}>
去结账
</button>
);
}请各位观众屏住呼吸。 运行这段代码。
在 React 15 中，你会看到控制台输出：
点击的目标 ID: checkout-btn
异步回调中的目标 ID: undefined
卧槽！ 怎么回事？刚才明明是 checkout-btn，怎么一秒钟后，它就变成了 undefined？那个按钮跑哪去了？
这就是我们要讲的“幽灵”。
原因就在于对象池。
当你的 handleCheckout 函数执行完毕后，React 看到事件处理函数跑完了。它心想：“好，这个事件对象用完了，属性也用完了，把它放回池子里去！”于是，e.target 被重置为 null，e.type 被重置为空字符串，整个对象被“清空”了，准备给下一个事件使用。
但是，你的 setTimeout 回调函数还在那里，它紧紧抓着那个 e 对象不放（闭包）。当 1 秒钟后，setTimeout 回调执行时，React 可能刚好又从池子里抓出了同一个对象，用在了别的事件上（比如点击了另一个按钮）。
于是，React 把那个对象的状态重置了，把 target 擦掉了。
你的 setTimeout 回调拿到的是那个被擦得干干净净的“僵尸”对象，所以 e.target 是 undefined。
这就是 React 15 时代的噩梦。所有的合成事件属性（target, currentTarget, dataTransfer 等）在异步回调中都会变成 null 或 undefined。
第三部分：救世主降临——e.persist() 的魔法
面对这个幽灵，React 官方并没有选择放弃对象池（毕竟省内存是硬道理），而是祭出了一道符咒——e.persist()。
这个方法长这样：
const handleCheckout = (e) => {
// 1. 施展魔法：告诉 React 别动这个对象！
e.persist();
setTimeout(() => {
// 2. 现在安全了
console.log(e.target.id);
}, 1000);
};当你调用 e.persist() 时，React 会做什么？
React 会给这个合成事件对象打上一个标记，比如 isPersistent: true。
React 的事件分发机制是这样的：每当一个新的事件触发，React 会从池子里取出一个对象。它首先会检查这个对象是否被标记为 isPersistent: true。
- 如果标记为
false（默认）： React 会认为这个对象已经“退休”了，它会把对象的属性全部清空，放回池子，等待复用。 - 如果标记为
true（通过persist()）： React 会跳过“清空”这个步骤。它会把这个对象标记为“不可回收”或者“暂时隔离”，确保在当前事件处理函数及其所有闭包引用结束之前，这个对象不会被池化机制重写。
底层原理总结一下：
e.persist() 的本质，是告诉 React 的调度器：“嘿，这个对象现在被我的代码引用着呢，别急着把它放回池子，也别急着清空它的数据。等我用完了，你再把它扔进垃圾桶。”
这就像是你把一件脏衣服（事件对象）暂时挂在了衣架上（标记为持久化），而不是直接扔进脏衣篓（对象池），这样你随时都能再拿起来穿。
第四部分：为什么现代版本不再需要它？
时光飞逝，React 16.0 横空出世。Fiber 架构、并发模式、自动批处理……整个 React 的世界都被颠覆了。
随之而来的，是 e.persist() 的彻底消失。
在 React 16 和 React 17+ 中，e.persist() 依然存在（为了向后兼容），但它变成了一个空操作。
function MyComponent() {
const handleClick = (e) => {
e.persist(); // 现在的 React 里，这行代码就像 `console.log('hi')` 一样，什么都没做
console.log(e);
};
return <button onClick={handleClick}>Click</button>;
}为什么？为什么我们不再需要那个救命稻草了？
原因很简单：React 放弃了“事件对象池”。
在 React 16 的重构中，React 团队发现，为了维护一个复杂的对象池（需要追踪哪些对象被 persist() 了，哪些被清空了），给开发者带来的心智负担远远超过了它带来的性能收益。尤其是配合 Fiber 这种复杂的调度机制，对象池的状态同步变得极其困难。
所以，React 做了一个决定：每次事件触发，都创建一个全新的、干净的合成事件对象。
旧版流程：
- 池子里抓一个对象 -> 擦干净属性 -> 给用户用 -> 用完放回池子 -> 被下次复用 -> Bug！
新版流程：
- 造一个全新的对象 -> 给用户用 -> 用完不管 -> 垃圾回收器（GC）把它收走 -> 完美！
既然每次都是全新的对象，闭包里拿到的 e 肯定是完整的，不需要 persist() 来保命。
第五部分：源码考古——到底改了什么？
为了证明我的观点，我们来扒一扒 React 的源码（以 React 15 和 React 18 为例）。
1. React 15 的 SyntheticEvent.js
在旧版本中，SyntheticEvent 类是这样的（简化版）：
const eventInterface = {
// ... 各种属性
};
let pool = []; // 池子
function SyntheticEvent(topLevelType, targetInst, nativeEvent) {
// 从池子里取
this.type = topLevelType;
this.target = targetInst;
this.nativeEvent = nativeEvent;
// ...
}
SyntheticEvent.prototype = {
// 核心方法：清理属性并归还给池子
release: function() {
// 把所有属性重置为 null 或 undefined
this.type = null;
this.target = null;
// ... 其他属性
// 放回池子
pool.push(this);
},
// 核心方法：persist
persist: function() {
this.isPersistent = function() {
return true;
};
}
};
// 事件分发逻辑
function dispatchEvent(topLevelType, nativeEvent) {
// 1. 从池子取一个对象
var event = pool.length ? pool.pop() : new SyntheticEvent();
// 2. 填充数据
// ...
// 3. 调用用户函数
listener(event);
// 4. 如果用户没 persist，就释放对象
if (!event.isPersistent()) {
event.release();
}
}看懂了吗？release 方法就是那个“擦黑板”的人。如果没有 persist()，它就会执行 release，导致你的 e.target 变成 null。
2. React 18 的 SyntheticEvent.js
现在，让我们看看现代版本。虽然 React 源码非常庞大且抽象，但核心逻辑变了。
在现代 React 中，你再也找不到那个 pool 数组了。
// React 18 (简化伪代码)
function createSyntheticEvent(nativeEvent) {
return {
type: nativeEvent.type,
target: nativeEvent.target,
currentTarget: nativeEvent.currentTarget,
// ... 其他属性
// 移除了 release 方法
// 移除了 pool 数组
// persist 方法现在只是一个空函数
persist: function() {
// No-op
}
};
}
function dispatchEvent(topLevelType, nativeEvent) {
// 1. 创建全新的对象，不需要从池子里抢
const event = createSyntheticEvent(nativeEvent);
// 2. 调用用户函数
listener(event);
// 3. 事件对象被回收，但不需要手动放回池子了，GC 会自动处理
// 不再需要检查 isPersistent
}这就是为什么 e.persist() 在现代版本里是个空操作。因为没有池子，就不存在“被复用”的风险，自然也就不需要“拿出来”这一步了。
第六部分：深度剖析——为什么 React 团队决定放弃池化？
有人可能会问：“老大，既然池化能省内存，为什么 React 16 不继续用呢？”
这是一个非常深刻的技术决策问题。这里涉及到 React 的两个核心矛盾：
-
内存与复杂度的博弈：
React 的事件系统需要处理几十种不同的事件类型（MouseEvent,KeyboardEvent,TouchEvent等）。每个事件对象都有几十个属性。为了省内存而引入对象池，导致代码逻辑变得极其复杂（你需要处理属性清空、状态恢复、线程安全等）。开发者为了用这些属性，还得去学e.persist()。这得不偿失。 -
Fiber 架构的兼容性问题：
React 16 引入了 Fiber。Fiber 的核心是时间切片和优先级调度。这意味着，事件处理函数的执行可能会被打断，或者在不同的 Fiber 节点之间传递。如果对象池里的对象被多个地方同时引用（比如一个异步任务引用了事件对象，同时 React 的内部逻辑也在复用它），这就引发了严重的竞态条件和数据竞争。在现代 JS 引擎的垃圾回收机制下，创建新对象的开销其实并没有想象中那么大，而带来的逻辑清晰度提升是巨大的。
第七部分：实战演练——如何优雅地处理异步事件
既然 e.persist() 已经退出了历史舞台，那么在 React 16+ 中，我们应该如何处理异步访问事件属性的问题呢？
方案 A：直接保存引用（推荐）
既然对象是新的，那就直接把它存下来。
function MyComponent() {
const handleAsyncClick = (e) => {
// 1. 直接解构并保存
const { target, clientX } = e;
// 2. 异步访问
setTimeout(() => {
console.log(target.id); // 正常
console.log(clientX); // 正常
}, 1000);
};
return <button onClick={handleAsyncClick}>Click</button>;
}这种方式最简单，最直观，完全不需要任何魔法咒语。
方案 B：使用 ref 获取 DOM 元素（最佳实践）
如果你在异步操作中需要频繁访问 DOM 元素（比如修改样式、获取坐标），直接在 onClick 里拿 e.target 是不安全的，因为 e.target 可能会变化（比如你点击了一个按钮里的 span）。
这时候，React 的 ref 是你的好朋友。
function MyComponent() {
const buttonRef = useRef(null);
const handleClick = () => {
// 保存 ref 的当前值，而不是依赖事件对象
const currentButton = buttonRef.current;
setTimeout(() => {
// 即使组件重新渲染了，currentButton 指向的还是真实的 DOM 节点
console.log(currentButton.id);
currentButton.style.backgroundColor = 'red';
}, 1000);
};
return (
<button ref={buttonRef} onClick={handleClick}>
点击我
</button>
);
}这种方式不仅解决了异步问题，还避免了 React 事件系统带来的任何不确定性，性能也更好。
方案 C：useEffect 或 useLayoutEffect（针对副作用）
如果你的异步操作是在组件渲染后进行的，并且需要访问事件对象，确保在组件挂载后再访问。
function MyComponent() {
useEffect(() => {
// 这里的 e 已经是旧的了，所以不要在 useEffect 里访问 e.target
// 如果你需要，应该通过 props 或 state 传递
}, []);
}第八部分：总结与展望
好了，各位同学，今天的讲座接近尾声。
我们回顾了 React 事件系统的演变史：
- React 15 时代： 为了极致的内存优化，React 引入了事件对象池。这导致了在异步回调中访问事件属性（如
e.target）时出现undefined的 Bug。 e.persist()的作用： 它是一个“反池化”的机制，告诉 React 暂时不要把对象放回池子，保留其状态供闭包使用。- React 16+ 时代： 随着 Fiber 架构的引入，React 团队意识到对象池维护的复杂度和带来的 Bug 风险超过了性能收益。于是，React 放弃了对象池，每次创建全新对象。
- 结果：
e.persist()成为了一个空操作，彻底消失在历史的长河中。
给各位的建议：
- 如果你还在维护 React 15 的老项目： 请务必记住
e.persist()，或者更推荐的做法是：不要在异步回调里访问事件对象，直接解构变量或者使用ref。 - 如果你正在使用 React 18 或最新版本： 放心大胆地使用
e.target，不用担心它消失。别再写e.persist()了，那行代码现在看起来就像是在对着空气喊话，既多余又显得不懂历史。
React 的每一次版本迭代，都是在做减法。它删掉了复杂的内存管理，换来了更简洁、更健壮的代码。这就是 React 的魅力所在——在混乱中寻找秩序，在妥协中追求极致。
好了，今天的课就上到这里。下课！大家记得把垃圾带走，那个 e.persist() 的幽灵已经被我们彻底赶跑了。