嘿，我来帮你把这些PyQt信号槽的疑问掰扯清楚，结合Qt底层的信号机制给你明确的答案：

1. 信号槽引擎的正确行为是什么？ #

完全符合你期望的选项3！

当你触发mySignal的瞬间，Qt会对当前信号与槽的连接关系拍一个快照——也就是说，此时哪些槽函数和这个信号绑定，会被立刻记录下来。之后你断开旧连接、连接新对象的操作，不会影响已经触发并进入事件队列的sig_n，它依然会被准确发送给object_n的处理函数。

举个实际的例子：如果是跨线程的队列连接（你的场景正好是跨线程），信号触发后会被包装成事件放进接收线程的事件循环队列，这个事件里已经包含了目标槽的信息，后续的连接变更根本碰不到这个已经排队的事件。

2. 你对信号槽机制的认知是否准确？能否依赖队列的顺序性？ #

你的核心认知是对的，但可以补充一些细节让理解更完整：

• Qt确实有一套基于事件循环的信号槽调度机制，我们可以把它看作你说的Signal-Slot引擎：触发信号时，会根据连接类型（直接/队列/自动）决定是同步调用槽，还是把信号事件加入队列等待事件循环处理，同时会维护连接列表来追踪信号与槽的绑定关系。
• 队列的顺序性是完全可以依赖的：
  • 同一线程内的队列连接信号，会严格按照触发顺序进入事件循环，处理顺序和触发顺序一致；
  • 跨线程的信号，通过QCoreApplication::postEvent发送事件，同样会遵循先进先出的队列规则，不会出现乱序的情况。
    唯一需要注意的是直接连接：这种连接下信号触发会立刻同步执行槽函数，不会进入队列，此时如果槽函数耗时，会阻塞信号触发的线程。但你的场景是跨线程，默认会用队列连接，所以完全可以依赖队列顺序。

3. 频繁重连信号是否耗时？ #

disconnect()和connect()本身是轻量级操作，但如果是极端频繁的重连（比如每秒成千上万次），还是会产生一定的性能开销：

• Qt内部维护着信号与槽的连接列表，每次disconnect()需要遍历列表移除绑定，connect()需要添加新的绑定，这些操作虽然快，但累积起来也会占用少量CPU资源。
• 你的reconnect函数里用while True循环调用disconnect()直到报错，其实可以优化：如果是PyQt5/PyQt6，signal.disconnect()不带参数时会断开所有连接，不需要循环（不过早期版本可能需要用try-except处理无连接的情况，你的写法是兼容的）。

如果你的场景对性能比较敏感，其实可以换一种思路：不要频繁重连信号，而是写一个中间槽函数，让信号固定连接到这个中间槽，然后在中间槽里动态调用当前目标对象的处理函数。比如：

class YourClass(QObject):
    def __init__(self):
        super().__init__()
        self.mySignal.connect(self._middle_slot)
        self.current_target = None

    def _middle_slot(self, payload):
        if self.current_target is not None:
            self.current_target.handle_signal(payload)

    def emitterFunc(self):
        for obj in object_list:
            self.current_target = obj
            self.mySignal.emit(Foo())

这种方式只需要一次信号连接，后续只需要切换current_target，开销比频繁重连小很多。

内容的提问来源于stack exchange，提问作者K.Mulier