QML信号机制详解：从定义、连接到C++跨语言交互-平芜编程栈

1. 从零开始理解QML的信号机制

1.1 信号在QML中扮演的角色

做QML开发的朋友应该都有这种感觉：界面写起来是真的快，声明式布局、属性绑定、状态切换，一套组合拳下来一个页面就出来了。但一旦界面开始变复杂，组件之间要互相通知、联动、传参，很多人就开始犯迷糊了。这其中的核心，就是QML里的信号交互。

先别急着写代码，先想清楚一件事：QML的信号到底解决了什么问题？

界面开发本质上是在处理“事件”和“状态”的流动。用户点了按钮，列表要刷新；滑块拖动了，数值要显示；网络请求回来了，界面要更新。这些事件从产生到消费，中间总得有个传递机制。QML里的信号（Signals）就是这个“传递机制”的标准通道。它跟JavaScript里的事件回调思路一样，但语法更简洁、语义更清晰，而且天然支持跨语言——QML和C++之间的交互，主要就是靠信号来搭桥的。

我第一次用QML做项目时，犯过一个典型的错误：到处用属性绑定来做“隐式通信”。比如A组件改了某个属性，B组件通过Binding去监听这个属性。表面上看没问题，但项目一变大，绑定链变得又深又长，逻辑全散落在各个文件的绑定表达式里，调试的时候找半天找不到是谁改了谁。后来老老实实把关键交互全部改为信号通知，代码结构立刻清爽了很多。所以信号在QML里的价值，不仅仅是“能用”，更是一种组织代码、梳理依赖关系的设计工具。

1.2 信号、槽与信号处理器的本质区别

很多初学者会把QML里的“信号处理器”和C++里的“槽函数”混为一谈，虽然它们功能上确实对应，但机制上有差别。

在C++/Qt里，信号和槽是通过元对象系统（MOC）在编译期建立关联的，是一种函数级别的回调注册机制。而在QML里，当你写onClicked: {}这种代码时，它本质上是为某个信号注册了一个JavaScript回调函数。这个回调函数不是严格意义上的“槽”，但行为上可以等价理解。QML引擎在信号发射时，会同步调用这个处理器。

另一个容易混淆的概念是：signal关键字定义的信号，和property属性变化时自动产生的onPropertyChanged信号，其实是两种不同的东西。前者是你显式声明的“事件通知”，后者是引擎自动追加的“属性监视器”。两者都会触发对应的onXxx处理器，但设计意图完全不同。显式信号表达的是业务语义——比如loginSucceeded(message)，属性变化信号表达的只是数据层面的变动通知——比如onUserNameChanged。理解这个区别，写出来的代码可读性会好很多。

2. 在QML中定义与发射信号

2.1 信号声明的完整语法

QML中定义一个信号非常简单，就是在任意QML对象类型里加上signal关键字。

// 不带参数的信号 signal refreshFinished() // 带参数的信号 signal loginResult(code: int, message: string) // 带默认值的信号参数 signal progressUpdated(percent: real, status: string)

从Qt 5.15开始，QML支持了带类型标注的信号参数声明，这是在QML中加入类型系统增强的一部分。写参数类型的好处是让信号的自文档性更好，调用方一眼就能看出该传什么类型的数据。老版本的写法是signal loginResult(int code, string message)，两种写法都兼容，我建议新项目直接用带类型标注的写法。

还有一点容易被忽略：信号参数名是可以省略的。比如signal progressUpdated(real, string)，但这样在处理器里就只能用arguments[0]、arguments[1]去访问参数，可读性极差。所以除非是快速原型，否则建议永远带上参数名。

2.2 发射信号的时机与函数复用

要发射一个信号，直接把它当函数调用即可：

// 在某段逻辑里发射信号 loginResult(200, "登录成功")

这个调用的位置非常讲究。信号发射的时机，往往比信号本身更影响程序的正确性。我复盘自己踩过的坑，总结出三条时机铁律：

第一，信号发射前必须保证依赖数据已就绪。比如你有一个dataLoaded(listModel)信号，发射前必须先确认listModel里的数据已经填完。否则接收方拿到一个空模型，界面渲染就崩了。

第二，同一批状态更新要聚合为一次信号发射。有的初学者会在一个函数里连续发射多个信号：

function onDataChanged() { dataSizeChanged(listModel.count) dataReadyChanged(listModel.ready) dataUpdated() }

这三个信号其实表达的是同一个业务事件——数据更新了。拆成三个信号，接收方就要分别处理三次，而且中间状态很容易被别的代码插足，产生难以复现的时序问题。正确做法是合并成一个语义完整的信号：

signal dataUpdated(size: int, ready: bool) function refreshData() { // ...填充数据... dataUpdated(listModel.count, listModel.ready) }

第三，在构造函数或Component.onCompleted阶段发射信号要格外谨慎。此时很多关联组件可能尚未完成初始化，信号发出去没人接，或者接到了但对方的状态还没准备好。这属于典型的“太早了”问题，通常需要延迟到下一帧或等一个明确的初始化信号。

2.3 信号参数的数据类型选择

QML信号参数支持的类型很灵活，基本涵盖了QML的完整类型系统：

基础类型：int、string、bool、real、double
变体类型：var、variant（可传递任意JS对象）
QML对象类型：可以直接传一个Item、Component实例
列表类型：list、array（JS数组）
C++注册的自定义类型

遇到一个真实场景来说明类型选择的重要性。我在一个项目中需要把后端返回的数据包从C++层传到QML层，最初偷懒直接用var传了一个包含20多个字段的大字典。看起来很方便，但后续排查问题时发现：第一，IDE里对var字段没有任何补全提示，写错键名运行时才报 undefined；第二，性能上每次都要做JS对象与QVariant之间的转换。

后来我把这个数据包封装成C++类并注册到QML，用信号直接传自定义类型的实例。代价是多写了一点C++代码，但换来的是编译期就能抓住大部分字段名错误，运行时性能也提升了，接收方在QML里访问属性还有补全提示。这笔账，怎么算都划算。

3. 信号连接的三种主流方式

3.1 onSignalName信号处理器——最常用、最推荐

这是QML中最常见的信号连接方式，语法就是在信号名前加on，首字母大写：

Button { onClicked: { console.log("按钮被点击了") } } Text { onTextChanged: { console.log("文本变化了:", text) } }

信号处理器有几个特点值得注意。

作用域问题。处理器内能直接访问信号所属对象的属性和同作用域内的其他对象。比如：

Item { id: root property bool isBusy: false signal taskStarted(taskId: int) onTaskStarted: { // 这里可以直接访问 isBusy、root 下的其他子对象 console.log("任务开始:", taskId, root.isBusy) } }

这个内联作用域让代码写起来很顺手，但也容易引起命名遮蔽问题。如果处理器里用了一个变量名，恰好跟外部对象id重了，调试起来非常头疼。我的习惯是：处理器内部只访问根对象的属性，不直接在处理器里跟深层子对象发生关系，需要访问时先通过id显式指定。

信号处理器中的arguments。假设信号声明时参数没命名，比如第三方组件里的信号只有类型声明，处理器里就可以用arguments[index]来访问。此外，即便参数有名字，arguments对象依然可用。这在做日志打印或者参数转发时特别好用——你可以在一个处理器里把整个参数列表转发出去，而不需要逐个列参数名。

3.2 Connections动态连接——目标不固定的首选

Connections元素用于连接“不一定能直接写onXxx”的信号。最常见的两种情形：

情形一：连接的对象可能是动态创建或者可能变化的。

Item { Connections { target: someLoader.item // 这个item可能在运行时变化 onLoaded: { console.log("加载完成") } } }

情形二：需要把外部信号连接到当前组件，但当前组件的根元素不是信号源。

Item { id: root // 注意：不能直接写 onSomeSignal，因为根元素没有这个信号 Connections { target: childComponent onSomeSignal: { // 当前作用域内可以使用 root 的属性 } } }

Connections还有一个很有用的属性：enabled。设为false时，连接暂时失效，但连接关系保留。这在做界面开关、调试开关时特别方便。例如有一个日志信号，正式发布时把enabled绑到配置项上，就能一键关闭所有信号打印，而不用删代码。

还有个小技巧：当target省略不写时，Connections默认连接它所在的父对象。但我不推荐依赖这个隐式逻辑，代码可读性差，还是明确写target比较好。

3.3 connect()函数手动连接——动态注册与解绑

Connections适合静态声明，而如果想在JavaScript代码里动态建立信号连接，就要用connect()函数：

// 存一个函数引用，方便后续断开 function handleTaskComplete(taskId) { console.log("任务完成:", taskId) // 做点啥... } Component.onCompleted: { taskManager.taskCompleted.connect(handleTaskComplete) } Component.onDestruction: { taskManager.taskCompleted.disconnect(handleTaskComplete) }

注意两个容易踩的坑。

坑一：connect一个匿名函数后，无法再用disconnect解绑。因为disconnect需要传入同一个函数引用，匿名函数你没地方存引用。所以需要动态解绑时，必须先把函数声明成具名函数，或者用变量保存匿名函数的引用。

坑二：多次connect同一个信号和同一个函数，会重复注册。这意味着该函数会被调用多次。把connect放在一个反复执行的逻辑里（比如每次点击都connect一次），就会越积越多，最终导致函数被调用N次，而且极难排查。建议在connect前先disconnect一次，幂等处理：

taskManager.taskCompleted.disconnect(handleTaskComplete) taskManager.taskCompleted.connect(handleTaskComplete)

这样写虽然多了一行代码，但能彻底规避重复注册问题，我实测下来很稳。

3.4 三种连接方式的选择标准

每个人的习惯不同，但我的经验是按以下规则选型：

连接方式	适用场景	优势	劣势
`onSignalName`	信号源在当前作用域内固定	语法简洁、可读性好、作用域内可直接访问属性	无法动态解绑
`Connections`	目标可能变化、或当前root无该信号	可动态切换target、可控制enabled	不能像onSignalName那样直接访问作用域内全部属性
`connect()`	需要在JS逻辑中动态控制连接生命周期	灵活、可精准解绑	需手动管理生命周期、匿名函数无法解绑

这么说可能有点抽象。举个例子：一个列表项Repeater中，每个delegate里都有一个Button，需要把点击信号转发给外面的控制器。此时如果在delegate里写onClicked，信号就在delegate内部处理了；但如果delegate本身就是动态创建的，控制器对象随时可能变化，用Connections动态绑定target就是更稳妥的方案。

4. QML与C++的信号交互

4.1 从QML发射信号到C++层

这是最常规的跨语言交互方向。QML里发射一个信号，C++层接收并处理业务逻辑。

具体可以分为三步。

第一步：定义C++接收类，注册到QML。

class BackendManager : public QObject { Q_OBJECT public: Q_INVOKABLE void handleLogin(int code, const QString &message) { qDebug() << "Login callback from QML:" << code << message; // 在这里处理业务 } };

在main.cpp里注册：

qmlRegisterType<BackendManager>("App.Backend", 1, 0, "BackendManager");

或者如果在QML里直接用单例对象，则用qmlRegisterSingletonInstance。

第二步：QML侧声明信号并发射。

import App.Backend 1.0 Item { signal loginRequested(code: int, message: string) BackendManager { id: backend } function doLogin() { loginRequested(200, "用户已登录") } }

第三步：在C++里连接QML对象的信号。

这里有一个关键细节：QML对象在C++侧被视为QObject *。要连接它的信号，需要拿到该对象的指针，然后使用标准的QObject::connect。

QObject *rootObject = engine.rootObjects().first(); QObject *item = rootObject->findChild<QObject *>("loginItem"); if (item) { QObject::connect(item, SIGNAL(loginRequested(int,QString)), backend, SLOT(handleLogin(int,QString))); }

这段代码里有个退化陷阱：使用SIGNAL/SLOT宏进行字符串式连接，写错了信号签名不会被编译期捕获，运行时才报“No such signal”。建议使用基于模板的PMF（Pointer to Member Function）语法，编译期就能检查出问题：

QObject::connect(item, &QObject::signal, ???);

但问题是，QML对象里的信号是动态生成的，不是C++类编译时期已知的成员，所以无法用PMF语法直接连接。这是QML与C++交互中的一个客观限制，只能用SIGNAL/SLOT宏方案，签名必须严格匹配。我的经验是：在这种场景下，把信号参数类型统一写成QVariant或者尽可能使用int、QString这类基础类型，能显著降低签名匹配出错的概率。

4.2 从C++发射信号到QML层

反向交互同样重要。C++层要通知QML刷新界面、弹窗提示、更新状态，最规范的做法是定义一个QObject派生类中的signal，然后在适当时候emit。

class BackendManager : public QObject { Q_OBJECT signals: void dataArrived(QString jsonData); public: void simulateNetworkResponse() { QString temp = "{\"name\":\"Qt\"}"; emit dataArrived(temp); } };

QML侧处理：

Item { Connections { target: backend onDataArrived: { console.log("收到数据:", jsonData) // 解析JSON并更新界面 } } }

这里要特别注意信号参数在QML中的类型映射。C++的QString在QML里自动映射为string；int、double映射为int、real；如果是自定义类型，需要qRegisterMetaType注册后才能跨线程安全传递。如果遇到了信号参数发过来变成 undefined 的情况，十有八九是类型映射问题。

4.3 跨语言交互的线程与生命周期问题

QML与C++之间信号连接的另一个经典坑是线程问题。

Qt的信号槽机制本质上是线程安全的，但前提是连接类型设置正确。QML运行在主线程（GUI线程），如果你在C++的工作线程里emit信号，而这个信号连接的是QML侧的对象，默认的连接类型是AutoConnection，它会根据接收者所在线程自动决定是直接调用还是排队调用。大多数时候这个机制能正确工作，但如果发射信号的线程和QML对象的线程判断有误，就可能出现回调不触发、或者触发了但操作了非线程安全的对象导致崩溃。

跨线程交互的安全姿势是：C++业务逻辑尽量跑在自己的线程里，信号发射用QueuedConnection明确指定，并确保所有UI操作最终回到GUI线程：

// 在C++侧显式指定排队连接，保证QML槽在GUI线程执行 QObject::connect(worker, &Worker::dataReady, receiver, &Receiver::onData, Qt::QueuedConnection);

从生命周期角度看，还要注意：当QML对象被销毁时，C++侧持有的指针会变成野指针。不论用哪种方式连接，都应在Component.onDestruction或对象销毁时断开连接。C++侧如果长期持有了某个QML对象的指针，用QPointer或QWeakPointer管理会更安全。

这个跨语言交互的设计，其实不仅仅是“把信号连起来”，更是边界设计。一个干净的分层思路是：C++层只负责业务逻辑和数据处理，通过信号抛出“业务事件”；QML层只负责界面展示和用户操作，通过信号抛出“用户意图”。中间不直接调用对方的内部函数，而是通过信号解耦。这样架构下，替换任何一层的实现，都不需要动另一层的代码。

5. 信号交互的实战案例

5.1 组件间通信的经典模式：兄弟组件搭桥

一个很常见的界面场景：左侧是一个设置面板（SettingsPanel），右侧是一个预览区域（PreviewArea）。用户在左侧调整颜色，右侧要实时刷新预览。这两个组件是兄弟关系，它们之间没有父子关系，直接互相访问在QML里并不优雅。

最经典、最推荐的模式是“通过父组件搭桥”——两个兄弟组件都不直接互访，而是各自向父组件发射信号，由父组件协调双方。

Item { id: root SettingsPanel { id: settings // 用户调节颜色时发出信号 signal colorChanged(newColor: color) onColorChanged: { preview.setNewColor(newColor) } } PreviewArea { id: preview function setNewColor(c: color) { // 更新预览 } } }

这种做法把“谁负责协调左右”这一职责收敛到了父组件一层，两个子组件既不用知道对方存在，也不用管对方怎么实现，耦合度极低。后期无论是换掉设置面板，还是给预览区域加动画，改动范围都限定在局部。

5.2 Repeater中委托的信号转发

Repeater是QML中高频使用的组件。它根据一个模型反复创建delegate，每个delegate内部可能有Button、CheckBox等可交互组件。这里有个经典难题：每个delegate的Button点击时，如何知道是哪一个delegate的按钮被点了？

最原始的办法是在delegate里直接处理，但delegate通常是无状态的UI描述，业务逻辑一般要放到外层。所以需要一种“信号转发+索引标记”的变通方案。

推荐做法是在delegate的根元素里定义一个转发信号，并携带索引：

Repeater { model: appListModel delegate: Item { id: itemDelegate width: 100 height: 50 signal itemClicked(itemIndex: int) Button { anchors.fill: parent text: model.name onClicked: { // 明确指定参数传递 itemDelegate.itemClicked(index) } } } }

外层接收时：

Item { Repeater { id: repeater model: appListModel delegate: ... } Connections { target: repeater // 注意：Repeater没有itemClicked信号，这里需要监听的是每个delegate发出的信号 } }

等等，Connections的target是Repeater本身，而delegate的信号并不属于Repeater。这里不能用一个Connections监听所有delegate的信号。正确做法是在delegate内部直接处理，或者通过每个delegate的itemClicked信号在delegate根部的信号处理器中做转发。

我实践中最常用的方案是直接让delegate内的ButtononClicked里调用一个外层传入的JS函数：

// 在外层定义处理器函数 function handleItemClicked(index) { console.log("点击了第", index, "项") } Repeater { model: appListModel delegate: Item { Button { onClicked: { // 调用外层函数，传入当前索引 root.handleItemClicked(index) } } } }

这种写法本质上是“每个delegate内部直接绑回调”，配合index上下文变量来传递索引。实际用下来代码量最少，也不容易出错。

如果你的delegate比较复杂，或者想统一管理信号，比较推荐的做法是给delegate的根元素封装信号，然后在外层遍历Repeater的itemAt(index)来连接。但QML的Repeater提供的是itemAt()方法，可以按索引拿到delegate实例，这时就能用connect()动态连接每个delegate的转发信号。这种方式适合动态增删模型项的场景。

5.3 用信号实现ViewModel解耦

现代QML开发中，很多人开始采用类似MVVM的架构意识。在这种架构下，界面通过View层暴露的“用户意图信号”通知ViewModel，ViewModel处理完业务后，通过“状态属性变化”或者“业务信号”回吐结果，从而让视图层和业务层彻底解耦。

一个典型的ViewModel信号设计示例：

// ViewModel 对象（通常来自C++侧） Item { id: viewModel signal loginSucceed(userInfo: var) signal loginFailed(errorCode: int, errorMsg: string) function onLoginBtnClicked(username, password) { // 方案A：直接在JS里做业务 // 方案B：调用C++单例方法 backend.login(username, password) } } // View 层 Item { id: root TextField { id: userInput } TextField { id: pwdInput } Button { text: "登录" onClicked: { viewModel.onLoginBtnClicked(userInput.text, pwdInput.text) } } Connections { target: viewModel onLoginSucceed: { // 跳转页面 root.state = "loggedIn" } onLoginFailed: { // 显示错误提示 } } }

这里面有一个细节：ViewModel中处理“登录按钮被点击”的函数，其实也可以设计成signal loginButtonPressed(username: string, password: string)，然后由View层去connect。但那样的话，View层需要在Connections里写handler，而handler里再去触发业务逻辑，代码分两层跳来跳去，不够直接。我现在的习惯是：View层调用ViewModel的Q_INVOKABLE函数，ViewModel通过信号回吐结果。函数调用用于“请求”，信号用于“通知”，语义清晰，分工明确。

6. 常见问题与排查技巧

6.1 信号处理器不触发：最容易被忽略的五个原因

信号机制本身并不复杂，但实际开发中“信号不触发”或者“信号触发了但没执行期望代码”的问题，出现频率极高。我概括出五个最常见的原因，基本都是亲手踩过的坑。

原因一：信号名拼写错误。这个问题在onSomeCustomSignal这种自命名信号上尤其突出。QML里信号处理器的名字是把信号名首字母大写、前面加on，比如dataUpdated对应onDataUpdated。拼写错误不会有任何编译期报错，因为QML把onXxx当成一个普通的属性赋值表达式，它不会校验那个信号到底存不存在。这种静默失败非常隐蔽。

排查方法：在QML里加一个临时Component.onCompleted日志，或者用控制台过滤QML Connections: Cannot assign to non-existent property这类警告。另外建议写一个小的类型检查脚本，用QQmlEngine加载QML时主动收集warning日志，很多人就是在日志里发现“cannot assign to non-existent property”时才知道自己拼错了。

原因二：信号发射时处理器尚未注册。比如在Component.onCompleted里调用了某个函数，而这个函数内部emit信号，但对应的Connections或onXxx处理器在这个时刻尚未建立连接。信号是一次性的，错过就没了，不会等你。解决办法是：把初始化信号延迟发射，或者用Qt.callLater推迟到当前事件循环处理完毕后再发。

原因三：空target导致Connections非活跃。Connections有一个警告是target为空时会产生null引用，但多数时候它不会抛异常，而是直接静默不工作。检查目标对象是否已被垃圾回收或尚未创建，是排查这类问题的主要方向。

原因四：信号参数个数/类型不匹配。比如signal dataReady(result: Object)，但发射时传了一个var，在某些Qt版本上，信号参数名不匹配或类型隐式转换失败时，处理器收到的可能是undefined。若处理器里做的是result.somefield，就立即报TypeError。为了避免这类问题，我建议信号参数尽量声明为var或者基础类型，少用复杂的自定义类，尤其不要隐式依赖自动转换。

原因五：多个信号处理器互相覆盖。这是QML一个特殊的坑：如果同一个对象被两个Connections连接，并且它们定义了同一个信号处理器，后定义的会覆盖先定义的。写代码时如果复制粘贴了Connections块，很容易出现这种“我以为两个处理器都会执行，结果只执行了一个”的怪象。

6.2 内存泄漏与悬挂处理器

信号连接属于典型的需要管理生命周期的资源。C++侧和QML侧都有各自的垃圾回收/内存管理机制，跨语言之后就容易出现“对象都释放了连接还在、或者连接还在但对象没了”的问题。

最典型的情况：在C++侧通过connect把QML对象的信号连接到一个C++对象的槽上，但C++对象的生命周期长于QML对象。当QML对象被销毁后，C++对象仍然持有这个连接，后续一旦有信号被错误地发射，就会访问一个已经释放的内存。虽然Qt本身有接收者销毁自动断开的机制，但前提是接收者（receiver）被正确销毁且系统能追踪到。如果设计上有隐藏泄漏点，就很难自动清理。

我的习惯是：所有跨对象信号连接，都在创建者或拥有者对象里用一个句柄管理或者统一断开；在析构函数或Component.onDestruction里显式调disconnect。多写的这几行代码，在项目后期排查问题时能省下大量时间。

6.3 调试信号的最佳实践

调试信号问题，不要靠肉眼盯代码。以下是我长期实践总结出来的高效调试方法。

方法一：“代理信号”打日志。如果想确认某个信号是否真的发射，在信号处理器里加日志是最直接的方式。但如果信号在深层嵌套的组件里，写真日志又麻烦，我习惯直接定义一个“代理信号”中转一层。例如在Item根元素里写onChildSignal: console.log("child signal received")，这样不下到子组件也能验证子组件是否发射了信号。

方法二：用Qt.callLater改变执行顺序。当怀疑多个信号间的时序有问题时，可以用Qt.callLater把某一个处理逻辑延迟到事件循环末尾：

onDataChanged: { Qt.callLater(() => { // 推迟执行，确保其他信号已处理完 refreshView() }) }

这招好用，但不可滥用，它只能作为临时排查手段，长期留着会让执行顺序变得不可预期。

方法三：检查QML context与引擎的warning输出。在main.cpp里安装一个消息处理函数，把Warn级别以上的Qt消息都打印到控制台。很多信号相关的坑，引擎其实有输出“Cannot assign to non-existent property on X”之类的提示，只是默认输出在特定日志通道中不容易被发现。设置一个统一的日志过滤器后，这些线索一目了然。

6.4 性能问题：信号过多导致界面卡顿

信号本身的开销很小，但信号多到一定程度，处理链越来越长时，性能问题就浮现了。一个按钮点击信号，最终触发了一系列信号处理器的级联调用，每个处理器里又发射新信号，形成一条很长的同步调用链。在调试性能问题时，我有个直观的判断标准：如果某个用户交互会导致界面明显卡顿，先把整个调用链里的耗时操作找出来。

信号发射是同步的，这意味着处理器里的JavaScript代码会阻塞UI渲染。如果处理函数里有大循环、频繁JSON解析、大量DOM/Item操作，界面就会卡。解决办法是：

用Binding延迟调用或Timer/Animation分帧处理大量更新
在处理器内避免执行耗时的同步操作，把它转移到后台线程或拆分成多帧
使用WorkerScript处理大计算量任务，处理完通过发信号把结果传回主线程

我经历过一次印象深刻的性能问题。一个列表页有上百个delegate，每个delegate的信号处理器都做了一次复杂的字符串拼接和模型访问，用户每滚动一次列表，就触发大量信号处理，结果在性能差的设备上滚动帧率掉到20帧以下。后来把计算提前到model层，delegate只做简单显示绑定，帧率一下就恢复了。

7. 写在最后的个人心得与补充技巧

信号机制看起来是QML里最小的一块知识点，但恰恰是这块小知识点，最能检验一个QML工程师对事件驱动架构的理解深度。从几十行的界面原型到几千行的商业应用，信号的组织方式决定了代码的可维护性和可扩展性。

我现在的代码习惯是：每个组件最多暴露3到5个业务信号，所有跨组件通信都走信号，不做深层次的直接函数调用。信号命名用“动词过去式”或“状态变化”来表意，比如loginSucceeded、dataReady、sectionExpanded。这些名字让同事读代码时几乎不需要看实现，就知道在什么时间点会有什么事件发生。

最后再分享一个小技巧：QML信号也支持in参数和out参数区分，但这一点经常被忽略。在信号声明里，默认参数都是“从信号源向外传递”的方向，你可以声明确实的参数值。但当信号处理器的返回值有意义时，是可以用function范式来做替代的。整体思路没那么玄，关键还是要把“谁通知谁”“什么时候通知”“通知什么数据”这三件事理清楚，然后放心大胆地用信号去解耦你的界面逻辑。