大家好，欢迎来到今天的“React 源码解密”特别讲座。我是你们的讲师，今天我们不聊怎么写 Hello World，我们聊聊 React 那个看不见、摸不着，但无处不在的“神经系统”——事件系统。
今天的话题有点硬核，甚至有点“原子物理”的味道。我们的话题是：在多线程并发环境下，React 如何保证事件处理的原子性，以及那个传说中的“冲突锁”到底是个什么鬼东西？
1. 浏览器：一个混乱的“多线程”派对
首先，我们要纠正一个误区。很多人觉得 React 是单线程的，所以它处理不了并发。其实，浏览器本身就是一个极其混乱的“多线程”派对。
想象一下，浏览器是一个巨大的公寓楼。
- 主线程：那是客厅，住着 JavaScript。它负责计算、逻辑、以及把 DOM 换上新衣服（渲染）。它是单线程的，大家得排队，不能打架。
- 渲染线程：那是隔壁的画师，它负责把客厅的家具（DOM 节点）画在墙上（屏幕上）。
- 网络线程：那是送外卖的，负责下载图片和脚本。
现在的问题是：用户在主线程疯狂点击按钮，与此同时，渲染线程正在画图，网络线程正在下载大图。如果主线程突然把客厅的椅子（DOM 节点）给拆了（卸载组件），而渲染线程正好正在画这张椅子，结果会怎样？崩！DOM 结构瞬间坍塌。
这就是所谓的“并发环境”。React 的任务，就是在这个混乱的派对里，保证当用户疯狂点击时，事件不会“丢”，状态更新不会“乱”，DOM 也不会“穿帮”。
2. 事件委托：那个“懒汉”守门人
在 React 出现之前，如果你有 100 个按钮，你得给每个按钮都挂一个 addEventListener。这就像是在 100 个房间里都装了摄像头，不仅内存爆炸，而且如果有人把其中一个房间拆了，那个摄像头的监听器还在，就像个幽灵一样飘着，最后导致内存泄漏。
React 的高明之处在于，它极度“懒”。它根本不给你每个按钮挂监听器。
源码逻辑：
React 只在 document 或者 root 这个最顶层的容器上挂一个监听器。
// React 内部大概是这样干的（伪代码）
function createRoot(container) {
document.addEventListener('click', handleTopLevelEvent);
// 它监听的是全宇宙的点击
}
function handleTopLevelEvent(event) {
// 1. 阻止冒泡（防止事件泄露到 React 外面）
event.stopPropagation();
// 2. 找到触发事件的 DOM 节点
const target = event.target;
// 3. 遍历 Fiber 树，找到对应的 React 组件
// 这就是事件委托的核心：找到“谁”被点了一下
const instance = findFiberFromHostNode(target);
// 4. 触发合成事件
dispatchEventForPluginEventSystem(instance, event);
}为什么这能防止丢失？
因为监听器只在顶层挂了一个。无论你点哪个按钮，这个监听器都会捕获到。只要这个监听器还在，事件就不会“丢”。它就像一个守门员，把所有的球（事件）都拦下来，然后交给裁判（React）去处理。
3. 合成事件：跨浏览器的“翻译官”
但是，光有监听器还不够。浏览器是野生的，IE 和 Chrome 对待事件的态度完全不同。IE 里事件是 window.event，Chrome 是 event 对象。还有那个烦人的 onsubmit 事件，在 IE 里如果不阻止冒泡，表单会真的提交刷新页面。
React 感到很烦。于是，它发明了 SyntheticEvent（合成事件）。
源码逻辑：
React 内部维护了一个巨大的 eventPool（事件池）。当你调用 onClick 时，React 并不是真的去调用浏览器的 onclick，而是创建了一个假的 SyntheticEvent 对象。
// React 源码中的 EventPluginHub
const eventTypes = {
onClick: {
phasedRegistrationNames: {
bubbled: 'onClick',
captured: 'onClickCapture'
},
executionName: 'onClick',
}
};
// 所有的原生事件都会被“翻译”成这个统一的接口
class SyntheticEvent {
constructor(domEventName, targetInst, nativeEvent) {
this.type = domEventName;
this.target = targetInst; // 指向 Fiber 节点
this.nativeEvent = nativeEvent; // 保留原生事件引用
}
// 拦截 stopPropagation
stopPropagation() {
this.nativeEvent.stopPropagation();
}
// 拦截 preventDefault
preventDefault() {
this.nativeEvent.preventDefault();
}
}为什么这能防止冲突？
因为所有的浏览器差异都被封装在这个“合成层”里。React 不需要关心 IE 还是 Chrome，它只跟自己的 SyntheticEvent 打交道。这就像给所有人发了一样标准的制服，大家都是“React 员工”，互不干扰。
4. 原子性保证与“冲突锁”的本质
好了，重头戏来了。这才是你今天来听讲座想听的东西。
场景重现：
假设你有一个购物车页面。
- 你点击“增加数量”（触发
onClick）。 - 你紧接着点击“结算”（触发
onClick）。 - 这两个操作在浏览器看来是同时发生的，或者至少是在同一帧内触发的。
如果 React 没有做任何处理，会发生什么？
- 第一次点击：
addToCart函数执行，把状态改为count = 1，触发重渲染。 - 第二次点击：
checkout函数执行，把状态改为isCheckout = true，触发重渲染。
如果这两个更新是原子的（即要么一起成功，要么一起失败），那没问题。但如果它们之间有依赖关系，或者由于渲染太快导致状态错乱，那就是灾难。
React 是如何保证这种“原子性”的？它并没有用 C++ 那种 std::mutex（互斥锁）。React 使用的是调度队列和批处理。
4.1 批处理：那个把两个事件“锁”在一起的胶水
在 React 18 之前，如果你在 onClick 里调用 setState，React 会把它扔进一个队列。但是，如果这个队列里已经有一个更新正在处理，React 就会合并它们。
// React 内部的一个简化版 updateQueue
class UpdateQueue {
constructor() {
this.pendingState = null; // 暂存状态
}
enqueueUpdate(update) {
// 核心逻辑：如果有 pendingState，直接合并，不重新排队
if (this.pendingState) {
this.pendingState = this.merge(this.pendingState, update.state);
} else {
this.pendingState = update.state;
}
}
}这就是“锁”的等价物。它锁住了事件流，确保在同一个事件处理周期内，多次 setState 只会触发一次重渲染。这保证了状态更新的原子性。
4.2 Fiber 架构与并发模式：真正的“多线程”调度
React 16 以前，是同步渲染。主线程算得慢，用户就会觉得卡。React 16 引入了 Fiber，这玩意儿本质上是一个链表结构，它把巨大的渲染任务切成了无数个“微任务”。
现在，让我们回到“多线程”的问题。虽然 JS 是单线程，但浏览器允许我们在两个任务之间插入其他任务（比如渲染一帧）。
React 18 引入了 并发模式。
// 模拟 React 18 的并发更新逻辑
function handleConcurrentClicks(event) {
// 1. 创建两个更新
const update1 = { state: 'first' };
const update2 = { state: 'second' };
// 2. 并发调度
// React 把 update1 放入调度队列，然后立刻去处理 update2
scheduleUpdate(update1, () => {
console.log("Update 1 finished"); // 这里的回调执行顺序是不确定的
});
scheduleUpdate(update2, () => {
console.log("Update 2 finished");
});
}它是如何防止丢失的？
Fiber 架构引入了 isBatchingUpdates 标志位。这是一个全局的“锁”。
// React 源码中的 isBatchingUpdates
let isBatchingUpdates = false;
function batchedUpdates(fn) {
// 1. 加锁：进入批处理模式
isBatchingUpdates = true;
try {
// 2. 执行事件处理函数
return fn();
} finally {
// 3. 解锁：把队列里的所有更新一次性提交
isBatchingUpdates = false;
flushPendingUpdates();
}
}代码示例：冲突演示
假设没有这个“锁”（即没有批处理），会发生什么？
// 错误示范：没有原子性保证
let count = 0;
function handleClick() {
// 第一次点击
count++;
console.log("After click 1:", count); // 应该是 1
// 如果这里 setTimeout 一下，主线程去渲染了
setTimeout(() => {
// 第二次点击
count++;
console.log("After click 2:", count); // 变成 2
// 此时 DOM 还没更新，用户看到的是 1，但数据是 2
}, 0);
}
handleClick(); // 用户点击一次，实际上执行了两次逻辑React 的正确姿势（原子性）：
// React 正确姿势：使用 batchedUpdates 模拟
let count = 0;
let isLocked = false;
function handleClick() {
// 锁住状态，防止中间状态被外部读取
isLocked = true;
count++;
console.log("Inside handler:", count); // 1
// 模拟 React 的调度：把更新放入队列，但不立即渲染
// 此时 count 仍然是 1（中间状态）
// 只有当锁解开，或者调度器决定提交时，count 才会变成 2
// 用户在渲染过程中看到的永远是 1，直到渲染完成
setTimeout(() => {
isLocked = false; // 解锁
// 强制同步刷新（类似 flushSync）
console.log("Final count:", count); // 2
}, 100);
}5. 深入源码：EventSystemNode 与 双缓冲
React 是如何处理那些复杂的事件冒泡和捕获的呢？它使用了一个叫 EventSystemNode 的结构。
// 简化版的 EventSystemNode
class EventSystemNode {
constructor(fiberNode) {
this.fiberNode = fiberNode;
this.eventHandlers = []; // 存储这个节点上的事件监听器
this.nextSibling = null;
}
// 事件冒泡链
traverseUp(callback) {
let current = this;
while (current) {
callback(current.fiberNode);
current = current.nextSibling;
}
}
}React 使用了两棵树来处理并发：
- Current Fiber Tree：当前正在渲染的树。
- Alternate Fiber Tree：正在构建的树。
当你更新状态时，React 会构建一个 Alternate 树。如果在这个过程中，用户又触发了一个事件，React 会检查这个事件是发生在 Current 上还是 Alternate 上。
- 如果事件发生在
Current上，说明用户还在操作旧界面，React 会暂停新界面的渲染，优先处理这个事件（防止丢失）。 - 如果事件发生在
Alternate上，说明用户在操作新界面，React 会继续完成新界面的渲染。
这种机制保证了在多线程环境下（浏览器不断切换主线程和渲染线程），React 的事件流始终是有主见的，它知道该听谁的。
6. 防御性编程：如何自己实现一个“冲突锁”？
既然 React 的原子性这么重要，如果我们不想用 React，或者想在自己的原生 JS 项目里实现类似的逻辑，该怎么做？
我们可以写一个简单的 AtomicEventDispatcher。
class AtomicEventDispatcher {
constructor() {
this.queue = [];
this.isProcessing = false;
this.lock = false; // 真正的锁
}
// 模拟 React 的 dispatch
dispatch(event) {
// 1. 将事件放入队列
this.queue.push(event);
// 2. 如果当前没有在处理队列，且没有锁住，开始处理
if (!this.isProcessing && !this.lock) {
this.processQueue();
}
}
processQueue() {
this.isProcessing = true;
// 使用 while 循环处理队列，模拟批处理
while (this.queue.length > 0) {
const event = this.queue.shift();
// 模拟事件处理逻辑
console.log(`Processing event: ${event.type}`);
this.updateState(event.data);
}
this.isProcessing = false;
}
updateState(data) {
// 这里是原子性更新逻辑
console.log(`State updated to: ${data}`);
}
// 外部调用者使用
handleClick() {
// 强制使用批处理模式
this.lock = true;
try {
this.dispatch({ type: 'click', data: 'First' });
// 这里如果再调用 dispatch，会被锁住，不会立即执行，而是进入队列
setTimeout(() => {
this.dispatch({ type: 'click', data: 'Second' });
this.lock = false; // 解锁，队列会被处理
}, 0);
} finally {
this.lock = false;
}
}
}
const dispatcher = new AtomicEventDispatcher();
dispatcher.handleClick();这个例子展示了核心思想：通过一个全局的 lock 变量（状态锁），将分散的事件调用串联成一个连续的原子操作。
7. 总结：React 的“锁”哲学
React 的事件系统并没有使用操作系统层面的互斥锁（Mutex），因为那太重了，而且 JS 单线程根本不需要。
React 的“冲突锁”是一种逻辑锁：
- 批处理锁 (
isBatchingUpdates)：锁住事件处理函数的执行，防止多个状态更新在中间状态被读取。 - Fiber 调度锁：锁住渲染任务，确保新的事件不会打断正在进行的、重要的渲染任务。
在多线程并发环境下，React 就像一个精明的交通指挥官。当红绿灯（事件）同时亮起，车流（事件流）拥堵时，它不会让每一辆车都乱窜，而是通过“原子性队列”和“调度锁”，强行把车流整理成一条有序的队列，确保每一辆车都能安全到达目的地，没有任何一辆车被遗忘在路边。
这就是 React 事件系统的精髓。它不仅处理点击，它处理的是时间和顺序。掌握了这一点，你就掌握了 React 并发的核心机密。
好了，今天的讲座就到这里。下课！