一、完全够用

是的——在绝大多数 Qt 工程 / 插件化系统中， 完全不做同步消息，不但“够用”，而且是“更优解”。

甚至可以说：

80%–90% 的稳定大型 Qt 系统，是“刻意禁止同步消息”的

二、为什么“没有同步消息”反而更稳？

从 Qt 的本质 说起。

1️⃣ Qt 的核心是：事件驱动，不是调用栈驱动

Qt 的设计哲学是：

事件 → 事件循环 → 回调

而同步消息的哲学是：

调用 → 阻塞 → 返回

这两者天然对立。

👉 在 Qt 里强行同步，通常意味着：

• QEventLoop::exec()
• BlockingQueuedConnection
• QSemaphore::acquire()

这些东西一旦进入 UI / 插件体系，死锁概率直线上升。

2️⃣ 插件化系统 = 动态、不确定、弱依赖

在插件系统里，同步调用隐含了几个“危险假设”：

👉 异步消息恰恰规避了所有这些假设

3️⃣ 工程现实：你真正“必须同步”的场景极少

把真实工程场景拆一拆 👇

三、90% 场景，用“纯异步”完全没问题

场景 1：模块状态变化

• 登录成功
• 配置变更
• 设备上线 / 下线

publish(UserLogin)publish(DeviceDisconnected)

✔️ 天然是事件✔️ 不需要返回值

场景 2：UI 驱动业务

• 点击按钮
• 菜单操作
• 参数修改

publish(SetConfig)

UI 不应该等待结果，只应该等待“状态变化事件”。

场景 3：数据生产 → 消费

• 采集线程 → 显示模块
• 解码模块 → 渲染模块

publish(FrameReady)

✔️ 高并发✔️ 高吞吐✔️ 同步反而会拖慢

场景 4：插件解耦（最关键）

插件间只“广播事实”，不“索要结果”

publish(ProjectOpened)

谁关心谁处理。

四、那“看起来需要同步”的场景，其实也不需要

下面是很多工程师误判的地方。

❌ 误区 1：我要“查一个值”，所以要同步

比如：

“我想从插件 B 拿一个配置值”

. 更好的异步设计：

publish(QueryConfig{key})

插件 B 回：

publish(ConfigValue{key, value})

UI 订阅 ConfigValue。

✔️ 解耦✔️ 可缓存✔️ 可重放

❌ 误区 2：启动阶段必须同步初始化

实际上：

• 插件启动 → 广播 PluginReady
• 系统聚合状态

publish(PluginReady)publish(AllPluginsReady)

👉 不要用“等”，用“状态推进”。

❌ 误区 3：错误必须立刻知道

异步系统里：

• 错误也是事件

publish(ErrorOccurred)

而不是：

if (!call()) returnfalse;

五、什么时候“真的需要同步”？（很少）

很负责任地告诉你：

如果你能数得出 3 个以上必须同步的点， 那说明架构已经开始变“紧耦合”了。

但还是给你列一下 极少数合理场景：

⚠️ 1️⃣ 插件是“服务”，不是“事件源”

例如：

• 算法插件
• 加密 / 解密
• 格式转换

这种插件本质是：

input → compute → output

👉 但 依然建议：

• 用 Future / Worker 线程
• 而不是 MessageBus 同步

⚠️ 2️⃣ 启动阶段的“能力探测”

比如：

“这个插件支不支持某功能？”

这种可以：

• 启动时缓存一次
• 后续全异步

六、行业经验

结合我在 Qt / 嵌入式 / 工业软件 / 插件平台 的经验：

很多成熟团队甚至会在 code review 中：

❌ 拒绝 BlockingQueuedConnection

七、“架构原则”

在事件系统里： 不要“等结果”，要“等状态”。

一旦你转成这个思维：

• 系统更稳定
• 插件更独立
• 线程问题大幅减少