这是个非常好的问题——QML的属性绑定更新和信号触发顺序确实容易让人困惑，尤其是涉及依赖链的时候。我结合Qt的官方规范和实际调试经验，给你梳理下具体的执行逻辑：

1. 单属性依赖场景的执行逻辑 #

先看你给出的代码示例：

property int myProp: 1000
property int myProp2: myProp

onMyPropChanged: console.log("myProp changed: ", myProp, " myProp2: ", myProp2)
onMyProp2Changed: console.log("myProp2 changed: ", myProp2, " myProp: ", myProp)

当你设置myProp = 2时，QML引擎的执行步骤是严格规定的：

• 第一步：直接更新myProp的数值为2，但此时依赖它的绑定属性myProp2不会立即重新计算。
• 第二步：立即触发onMyPropChanged信号槽，所以你会看到日志里myProp2还是旧值1000——因为绑定的重评估还没启动。
• 第三步：等onMyPropChanged的代码完全执行完毕后，QML引擎才会处理依赖队列，重新计算myProp2的绑定值（此时变为2）。
• 第四步：myProp2的数值更新完成后，立即触发它的onMyProp2Changed信号槽，这时两个属性都是新值了。

这里的核心规则是：属性变更信号会在自身属性更新完成后同步执行，而依赖该属性的绑定重评估，会延迟到当前信号槽执行完毕后才调度，这个顺序是明确的，不是未定义的。

如果有多个属性依赖同一个源属性（比如myProp同时被myProp2、myProp4绑定），它们的重评估顺序由QML引擎内部的依赖队列调度，但可以确定：所有依赖绑定的更新都会在源属性的变更信号执行完之后才开始，且每个依赖属性的变更信号会在自己的绑定重评估完成后立即触发。

2. 交叉依赖场景的执行逻辑 #

再看你的交叉依赖代码：

property int myProp3: myProp2 + myProp
property int myProp2: myProp
property int myProp: 1000

onMyPropChanged: console.log("myProp changed: ", myProp, " myProp2: ", myProp2, " myProp3: ", myProp3)
onMyProp2Changed: console.log("myProp2 changed: ", myProp2, " myProp: ", myProp, " myProp3: ", myProp3)
onMyProp3Changed: console.log("myProp3 changed: ", myProp3, " myProp: ", myProp, " myProp2: ", myProp2)

当设置myProp = 2时，执行流程是：

• 第一步：myProp更新为2，立即触发onMyPropChanged——此时myProp2还是旧值1000，myProp3因为还没重新计算绑定，所以保持旧值1000+1000=2000，对应你看到的第一条日志。
• 第二步：onMyPropChanged执行完毕后，引擎处理直接依赖myProp的myProp2绑定，计算出myProp2=2，更新后立即触发onMyProp2Changed——此时myProp3的绑定还没被重新计算，所以依然是2000，对应第二条日志。
• 第三步：onMyProp2Changed执行完毕后，引擎处理依赖myProp2的myProp3绑定，计算出2+2=4，更新后触发onMyProp3Changed，此时所有属性都是新值，对应第三条日志。

这里的关键是：绑定的重评估是按依赖链的层级逐步处理的——源属性变更触发自身信号后，引擎会先处理直接依赖的属性，每个属性更新后触发自己的信号，再处理下一层依赖该属性的绑定，以此类推。

另外补充两个重要细节：

• 如果绑定重评估后属性值没有变化（比如把myProp从2再设为2），QML引擎不会触发对应的变更信号。
• QML引擎会自动处理循环依赖（比如A依赖B、B依赖A），不会陷入死循环，因为它会追踪属性的实际值变化，避免重复无意义的计算。

内容的提问来源于stack exchange，提问作者Broothy