前端架构师 → C++/Qt 桌面架构师 · 成长系列
在 Web 前端，你早已熟悉"事件循环"——setTimeout 为什么是宏任务、Promise 为什么插队、长任务为什么卡帧。Qt 桌面端有一个结构上同源、细节上更硬核的事件循环：QCoreApplication::exec()。它是 Qt 应用的心脏——信号槽的跨线程投递、定时器、重绘、窗口系统消息，全部汇聚到这一个循环里调度。
不理解它，你写出的 Qt 程序要么偶发崩溃、要么 UI 卡死，而且很难定位根因；理解了它，前端的事件循环知识可以平滑迁移，还能顺手解决一批最难调的并发问题。今天这一篇，把事件循环的每个零件拆开讲透。
QCoreApplication::exec() 本质是启动一个 QEventLoop：循环反复执行"取事件 → 分发 → 等待新事件"。它不是忙轮询，而是阻塞在平台事件分发器上（Linux 上基于 glib、Windows 上是 Win32 消息、macOS 上是 CFRunLoop），有事件到达才被唤醒。所以一个空闲的 Qt 应用 CPU 占用接近 0——这是它和"while(true) 轮询"最本质的区别。
① PostedEvents：QCoreApplication::postEvent() 投递的事件，包括跨线程信号槽包装成的 QMetaCallEvent；② 定时器事件：QTimer 底层是 timerEvent，精度分 PreciseTimer / CoarseTimer（默认，5% 容差）/ VeryCoarseTimer；③ 套接字通知：QSocketNotifier，Qt 网络库底层靠它感知可读可写；④ 窗口系统事件：鼠标、键盘、绘制、窗口消息。此外还有同步的 sendEvent()——直接调用，不进队列，立即返回。
QCoreApplication::notify() 是总入口，QApplication::notify() 可重写做全局拦截；投递到目标前，先询问事件过滤器（installEventFilter，可消费或改写事件），再进入 QObject::event() 按类型路由，最后落到具体 handler（如 mousePressEvent）。快捷键（QShortcut 就是靠过滤器实现的）、输入法、拖拽命中判定，全部建立在这条链上。
① 异步 + 所有权转移：立即返回，事件必须 new 在堆上，队列投递后自动 delete——传栈对象是未定义行为；② 优先级：High / Normal / Low 三级，高优先级插队先处理；③ 压缩：自发事件（spontaneous，通常来自系统）入队时若已有同类型事件，会被合并——高频绘制类事件靠它降频。
Qt::QueuedConnection 会把槽调用包装成 QMetaCallEvent 投递到接收者所属线程的队列。这正是跨线程信号槽线程安全的原因：槽函数实际运行在接收者线程的事件循环里，天然无竞争。代价是：接收者线程必须活着且跑着事件循环，否则消息永远不处理——deleteLater() 失效、跨线程槽不触发，根因基本都是这个。
QObject 创建在哪个线程就属于哪个线程，事件由该线程的循环派发，moveToThread() 改变归属；QWidget 只能在 GUI 线程创建和使用，这是铁律。QDialog::exec()、QMenu::exec() 会启动嵌套事件循环——所以弹窗期间主窗口还能重绘。嵌套的代价是重入：你的槽还在栈上，同一信号可能再次触发它。标准武器：deleteLater、QPointer、状态标志。
事件循环只有一个线程在跑。任何槽里的长时间同步计算或阻塞 I/O 都会让整个循环停摆：定时器不响、重绘不刷新、点击无响应——UI 冻结。事件不会丢（还在队列里），但全部延迟。processEvents() 可以在长任务中手动泵循环，但重入风险极高，属于"知道但少用"的 API。
铁律：QWidget 只能在 GUI 线程创建与使用；任何阻塞 GUI 线程的代码都是架构缺陷，而不是"性能问题"。
| 机制 | 同步/异步 | 所有权 | 跨线程 | 典型用途 |
|---|---|---|---|---|
| sendEvent | 同步、立即 | 调用方（可用栈对象） | 不安全 | 需要即时返回的派发 |
| postEvent | 异步、入队 | 队列（自动 delete） | 目标线程循环 | 延迟处理、自定义消息 |
| queued 信号槽 | 异步、入队 | 队列 | 安全 | 线程间通信、模块解耦 |
Chrome / Chromium：主线程运行 base::MessagePump 消息泵，配合 Blink 的"任务队列 + 微任务队列 + 渲染步骤"模型。为什么滚动流畅？因为渲染按帧调度，长任务被切片执行，每片结束检查帧预算，超时就把控制权交还循环。这个"预算 + 切片"的思想，正是 Qt 端长任务分片上报的蓝本。
VSCode（Electron）：主进程管窗口菜单，每个渲染进程有独立事件循环，插件与渲染进程通信全部走异步消息。一个在主进程做同步 I/O 的插件能让整窗卡死——Electron 性能文档的第一条原则就是"不要在主进程做阻塞操作"，与 Qt 主线程铁律完全一致。
JetBrains IDEA：Swing 的 EDT（事件分发线程）就是它的主线程。SwingWorker 与异步任务把索引、编译、Git 操作全部扔出 EDT，完成后再把结果 post 回 EDT 更新 UI——所以大项目才能保持响应。JetBrains 的编码规范同样禁止在 EDT 上做阻塞调用。
Qt Creator：本身就是 Qt 应用。全局快捷键 QShortcut 靠事件过滤器实现；代码解析在后台线程完成，通过队列信号把结果送回 UI 线程刷新编辑器。类视图、错误列表就是 Model/View + 后台线程 + 队列信号的教科书组合。
微信 / QQ 桌面端：同为消息驱动架构——主线程循环接收系统消息，UI 更新一律投递到主线程执行，网络与解码在独立线程。这样动画与输入才能同时保持流畅。
嵌套循环的现实例子：QMessageBox::exec() 弹窗期间，为什么主窗口还能重绘、定时器还走？因为它开了嵌套循环，外层事件被继续分发。理解这一点，你才敢在业务里用 open()（异步、不阻塞）替代 exec()，避免无谓的重入风险。
错误 1：在槽里 sleep 或同步读大文件。原因：事件循环被独占，定时器、重绘、点击全部停摆，表现就是 UI 冻结几秒。避免：耗时任务进工作线程（QtConcurrent::run / QThread），或改用异步 API（QNetworkAccessManager、异步文件读写）。
错误 2：跨线程"直连"改 UI。原因：QWidget 非线程安全，跨线程直接调用就是裸数据竞争，崩溃只是时间问题。避免：默认用 auto 连接（跨线程自动变 queued）；必须显式时用 Qt::QueuedConnection；需要主动投递时用 QMetaObject::invokeMethod(obj, ..., Qt::QueuedConnection, ...)。
错误 3：postEvent 传栈对象。原因：队列投递后会对事件执行 delete，栈上 delete 是未定义行为，直接崩。避免：postEvent 一律 new；只有 sendEvent 可以用栈对象（它不转移所有权）。
错误 4：deleteLater 之后线程没有事件循环，或线程直接退出。原因：DeferredDelete 事件需要事件循环处理，循环不存在就永远不删——泄漏；若 deleteLater 后还访问对象，则是悬垂。避免：确认线程事件循环在运行；线程退出前显式 delete 或 wait()；槽内访问自己用 QPointer 守卫。
错误 5：事件过滤器生命周期失控。原因：过滤器对象先销毁，目标对象仍挂着它的指针，事件到来时悬垂调用崩溃。避免：过滤器析构里 removeEventFilter，或用"过滤器生命周期长于目标"的约定；Code Review 必查成对性。
1. GUI 线程零阻塞（铁律）。何时用：所有 I/O、计算、网络一律出主线程。何时不用：小于 1ms 的轻量逻辑不必小题大做。Trade-off：线程变多，线程所有权与生命周期管理成本上升——先测量再决定是否切线程。
2. 同线程也倾向用 queued connection 解耦模块。何时用：模块间通信、对可测试性要求高时——槽的调用点与执行点分离，便于 mock 与单测。何时不用：热路径上的高频调用（每次多一次事件入队开销）。Trade-off：延迟一个循环迭代、调试时调用栈断裂；换来线程安全与关注点分离。
3. 高频 UI 更新必须合并。何时用：日志流、进度条、实时图表——用节流（如 50~100ms 合并一次）或依赖 update() 的天然合并。何时不用：低频事件无需处理。Trade-off：合并粒度越大越流畅，但会丢失中间态，进度类场景要权衡。
4. 事件过滤器只用于"全局关注点"。何时用：快捷键、输入法、拖拽命中判定、全局日志钩子。何时不用：单点业务逻辑——那是事件处理器的事。Trade-off：过滤器是隐式拦截，滥用会让团队找不到"谁消费了事件"，务必少而清晰、成对移除。
5. 用 QTimer::singleShot(0, ...) 推迟非紧急工作。何时用：把"当前事件之后"才需要做的事（清理、批量提交、下一帧刷新）挪到下一轮循环。何时不用：需要立即生效的状态变更。Trade-off：推迟期间可能插入其他事件（重入窗口），记得加守卫。
结构同构：JS 事件循环 = 调用栈 + 宏任务队列 + 微任务队列；Qt = 事件分发线程 + PostedEvents 队列 + 定时器/套接字通知器。QTimer::singleShot(0) ≈ setTimeout(fn, 0)（推迟到下一轮）；postEvent ≈ 手动入宏任务队列；queued 信号槽 ≈ 宏任务。Promise 微任务的"当前宏任务结束后立即执行"在 Qt 没有原生对应——需要时可用"处理完当前事件后同步执行回调"的自定义调度近似。
React 批处理 ≈ 事件压缩：React 在事件处理函数内合并多次 setState，事件结束统一渲染；Qt 的 update() 合并同帧多次重绘、postEvent 对同类型自发事件压缩——同一个"同帧合并"思想，只是名字不同。
Node.js：libuv 分阶段循环（timers → poll → check）与 Qt 的事件源分类一一对应；worker_threads ≈ QThread + moveToThread；process.nextTick 与 setImmediate 的微妙差别，对应 Qt 里"同线程 queued 与跨线程 queued"的语义差异——它们都在回答同一个问题："下一个循环点在哪"。
长任务卡帧：浏览器 Performance 面板里 200ms 的长任务，就是 Qt 里 UI 冻结 200ms 的同一件事。诊断思路完全互通：找到主线程上的长函数，切片或移出主线程。
Vue 的 nextTick / scheduler 队列、requestAnimationFrame 的帧同步，也都能在 Qt 端找到同构体（singleShot(0) 后的统一更新、QQuickWindow 的 vsync 渲染）。知识迁移的关键，是建立"事件循环即调度中心"的心智模型——语言会变，调度思想不变。
架构决策：项目启动时就定下"线程所有权模型"——每个 QObject 归哪个线程、事件从哪来、到哪去，画一张图放进团队文档。这个模型比任何代码规范都值钱，它决定了并发 bug 的上限。
Code Review 检查单（按优先级）：①GUI 线程是否出现阻塞调用（sleep / 同步网络 / 大循环 / 同步文件）；②跨线程通信是否只用信号槽或队列调用，有没有直接指针操作；③deleteLater 是否在事件循环存活期内，有无泄漏风险；④事件过滤器是否成对移除；⑤exec() 嵌套有无重入守卫。
团队培养："能不能用事件循环讲清楚一个 bug"是客户端工程师的分水岭。要求成员用三句话描述故障——"哪个线程、哪个循环、处理了什么事件"——而不是只贴堆栈。能讲清楚的人，定位问题速度是别人的数倍。
梯队判断：能讲透事件循环的人，通常也能讲透线程模型、异步设计、性能剖析。这是面试客户端架构师时性价比最高的一个问题。
1. Qt 官方文档 The Event System（doc.qt.io/qt-6/eventsandfilters.html）——事件过滤器、postEvent 语义的第一手权威，先读它再读别的。
2. Qt 源码 qcoreapplication.cpp / qeventloop.cpp——直接读 postEvent 的压缩逻辑与 notify 分发链。Qt 源码就是最好的教程，比任何二手解读都准确。
3. HTML 标准 Event loop processing model（html.spec.whatwg.org）——浏览器事件循环的权威定义。与 Qt 对照着读，一次打通两端。
4. Node.js 官方文档 The Node.js Event Loop（nodejs.org）——libuv 分阶段模型，理解"下一个循环点在哪"的绝佳材料。
5. 《C++ GUI Programming with Qt》（Blanchette & Summerfield）事件与定时器章节——经典教材，纸质参考里仍然是最好的。
1. QTimer::singleShot(0, ...) 与直接调用有什么本质区别？什么场景下你会故意用它来"推迟"？
2. 为什么 QDialog::exec() 的嵌套循环是"受控"的，而自己在槽里写 while(condition) processEvents() 很容易出事？两者的重入风险差在哪？
3. 一个槽执行了 5 秒，期间投递的事件和定时器会怎样？会丢吗？恢复后按什么顺序处理？动手写代码验证你的答案。
4. 同线程 queued connection 的消息顺序有保证吗？跨线程呢？什么情况下顺序会出乎意料？
5. 每秒 1000 条日志刷到 QPlainTextEdit，为什么直接 append 会卡？如果让你设计一个不卡 UI 的日志面板，你的方案是什么？
任务：编译运行下面的程序，观察 sendEvent / postEvent / 队列信号 / singleShot(0) 的执行时机与顺序；然后完成"挑战"部分，验证你对事件循环的理解。
编译：Qt6 Core 即可，无需 Widgets。用 CMake 的 qt_add_executable 或直接：g++ -fPIC main.cpp $(pkg-config --cflags --libs Qt6Core) -o evloop
#include <QCoreApplication>
#include <QTimer>
#include <QEvent>
#include <QDebug>
// 自定义事件：携带序号，演示队列投递与优先级
class SeqEvent : public QEvent {
public:
static constexpr Type ET = static_cast<Type>(QEvent::User + 100);
int seq = 0;
explicit SeqEvent(int s) : QEvent(ET), seq(s) {}
};
class Sink : public QObject {
public:
using QObject::QObject;
protected:
bool event(QEvent *e) override {
if (e->type() == SeqEvent::ET) {
qInfo().noquote() << QString("[event] seq=%1").arg(static_cast<SeqEvent*>(e)->seq);
return true;
}
return QObject::event(e);
}
};
int main(int argc, char *argv[]) {
QCoreApplication app(argc, argv);
Sink sink;
qInfo() << "[1] sendEvent: 同步、立即分发(不进队列)";
SeqEvent direct(-1); // 栈对象只可用于 sendEvent
QCoreApplication::sendEvent(&sink, &direct);
qInfo() << "[2] postEvent: 入队，等事件循环(必须 new)";
QCoreApplication::postEvent(&sink, new SeqEvent(1));
QCoreApplication::postEvent(&sink, new SeqEvent(2), Qt::LowEventPriority);
QCoreApplication::postEvent(&sink, new SeqEvent(3), Qt::HighEventPriority);
qInfo() << "[3] 队列信号槽 + 定时器(事件源)";
QTimer timer;
QObject::connect(&timer, &QTimer::timeout, &sink,
[]{ qInfo() << "[queued] timer tick"; }, Qt::QueuedConnection);
timer.start(50);
qInfo() << "[4] singleShot(0): 推迟到下一轮循环";
QTimer::singleShot(0, &sink, []{ qInfo() << "[deferred] next loop"; });
qInfo() << "--- 进入事件循环 ---";
QTimer::singleShot(150, &app, &QCoreApplication::quit);
return app.exec();
}观察点：① seq=-1 最先出现（sendEvent 同步）；② 进入循环后 seq=3（High 优先级）先于 seq=1、seq=2；③ [deferred] 在 posted events 之后出现；④ timer tick 每 50ms 一次，直到 150ms 退出。
挑战：把 [2] 全部改成 sendEvent 再看顺序；把 connect 里的 Qt::QueuedConnection 参数去掉，观察同线程 auto 连接的行为差异；自己实现"压缩"——连续 post 5 个 SeqEvent，让 event() 里只处理最后一个（用成员变量覆盖旧值即可）。