一、事件驱动模型基础：理解事件循环、事件队列、事件处理器

事件驱动模型，说白了就是「等事情发生，然后处理它」。

你想想看，UI 程序跟命令行程序最大的区别是什么？命令行是你指挥它，它一步步执行。UI 程序反过来——它等着，等你点按钮、敲键盘、滑动鼠标。它不能一直轮询检查你有没有操作，那样 CPU 会炸。所以就有了事件驱动这套机制。

我个人习惯把事件驱动模型拆成三个核心部件：事件循环、事件队列、事件处理器。它们三个配合好了，UI 才能流畅响应。

1.1 事件循环——程序的心脏

事件循环就是一个死循环，一直在做两件事：取事件、派发事件。

伪代码大概长这样：

while (true) {
    event = eventQueue.waitAndTake();  // 从队列取事件
    dispatch(event);                   // 派发给对应的处理器
}

我在项目中遇到过一个问题：某个 UI 框架的事件循环里塞了一个耗时的文件写入操作，结果整个界面卡死了。为什么？因为事件循环是单线程的，它一次只能干一件事。你让它在循环体里做耗时操作，后续的事件就得排队等着。

1.2 事件队列——事件的缓冲区

事件队列就是一个先进先出的列表。用户点击、键盘输入、定时器到期、网络请求完成……这些都会变成一个个事件对象，被 push 到队列尾部。

事件队列的存在，解决了两个关键问题：

• 解耦生产者和消费者：产生事件的代码（比如鼠标驱动）不需要知道谁在处理它。
• 缓冲突发流量：用户短时间内疯狂点击，事件不会丢，只是排队等着处理。

我曾经调试过一个 bug：快速双击按钮时，第二个点击事件丢失了。查到最后发现是事件队列的容量设成了 1，第二个事件被直接丢弃。嗯，这种低级错误，框架文档里其实写了，但你没仔细看就容易踩坑。

事件类型	触发源	常见事件对象
鼠标事件	鼠标硬件 / 触摸屏	MouseEvent (x, y, button, modifiers)
键盘事件	键盘硬件	KeyEvent (keyCode, char, modifiers)
窗口事件	窗口管理器	ResizeEvent, CloseEvent, PaintEvent
定时器事件	系统时钟	TimerEvent (interval, repeat)
自定义事件	应用代码	任意自定义数据结构

1.3 事件处理器——真正干活的

事件处理器就是回调函数。事件循环把事件派发过来，处理器负责响应。

但这里有个容易被忽略的细节：事件处理器应该只做「响应」这件事，不要在里面做复杂计算或 I/O。

// ❌ 错误示范：在事件处理器里做耗时操作
onButtonClick(event) {
    let data = readLargeFileSync("data.bin");  // 阻塞！
    processData(data);
    renderUI();
}

// ✅ 正确做法：只记录状态，触发异步处理
onButtonClick(event) {
    this.pendingAction = "loadData";
    this.requestRepaint();  // 请求重绘，由刷新循环处理
}

我记得有一次接手一个遗留项目，界面点击后要等 3 秒才有反应。一查，事件处理器里直接做了数据库查询。这就是典型的事件处理器滥用。

1.4 三者如何协同工作

事件循环、事件队列、事件处理器，三者构成一个完整的流水线：

1. 外部输入（鼠标、键盘、网络）产生事件，放入队列。
2. 事件循环从队列头部取出事件。
3. 事件循环根据事件类型，找到对应的处理器并调用。
4. 事件处理器执行完毕后，控制权回到事件循环。
5. 循环继续取下一个事件。

这个流程看起来简单，但实际工程中会有很多变种。比如 Qt 的事件循环支持事件过滤、事件转发；Windows 的消息循环支持消息钩子；JavaScript 的事件循环还有微任务队列和宏任务队列的区分。

下面这张图，是我画的一个标准事件驱动模型流程：

1.5 实际工程中的常见陷阱

讲完理论，说几个我实际踩过的坑：

• 陷阱一：事件处理器里抛异常——如果异常没被捕获，事件循环可能直接崩溃。我建议所有事件处理器都包一层 try-catch。
• 陷阱二：事件循环里做 sleep——有人为了做定时任务，直接在循环里 sleep(100ms)。这是灾难，整个 UI 线程都停了。应该用定时器事件。
• 陷阱三：事件队列无限增长——如果事件产生速度大于处理速度，队列会撑爆内存。需要设置最大长度或丢弃策略。