Qt信号与槽是依赖元对象系统、线程模型和事件循环的通信基础设施，非简单语法糖；必须用函数指针写法（如&QPushButton::clicked）替代已淘汰的SIGNAL/SLOT宏，确保编译期类型检查；参数需严格匹配，重载时须用QOverload显式指定，Lambda可直接作槽。
Qt信号与槽机制不是“配个connect就能跑通”的语法糖，它是一套依赖元对象系统、线程模型和事件循环的通信基础设施。用错连接类型、忽略对象生命周期、传参类型不注册——这些都会导致信号静默、槽不执行、跨线程崩溃或内存泄漏。
connect 用函数指针写法，别再用 SIGNAL/SLOT 宏
Qt 5.0 之后，SIGNAL 和 SLOT 宏已淘汰，它们在运行时靠字符串匹配，拼错就静默失败，毫无提示。
必须改用函数指针语法，编译期就能检查签名是否匹配：
// ✅ 正确：编译时报错 if mismatch connect(button, &QPushButton::clicked, this, &MainWindow::onClicked); // ❌ 错误：拼错 clicked → clickd，编译通过但运行时不触发 connect(button, SIGNAL(clickd()), this, SLOT(onClicked()));
- 信号和槽的参数个数、类型顺序必须严格一致（const 引用、指针等也要对上）
- 如果信号重载（比如
valueChanged(int)和valueChanged(QString)），需用QOverload<int>::of(&MyClass::valueChanged)</int>显式指定 - Lambda 表达式可直接当槽用：
connect(btn, &QPushButton::clicked, [=]() { qDebug() ，但注意捕获的对象生命周期
跨线程发信号必须用 QueuedConnection，且参数类型要注册
默认的 AutoConnection 在同线程走 Direct，跨线程才转 Queued —— 但如果你没确保接收者对象的线程亲和性（QObject::moveToThread()），它可能误判为同线程，结果槽在子线程里直接调用，UI 崩溃。
安全做法是显式指定连接类型：
connect(worker, &Worker::resultReady,
this, &MainWindow::updateUI,
Qt::QueuedConnection);
- 所有跨线程传递的自定义类型（struct/class），必须先调用
qRegisterMetaType<mydata>()</mydata>，否则 Queued 连接会丢弃信号 - 基本类型（
int、QString、QByteArray等）和 Qt 容器已内置注册，无需额外操作 - QueuedConnection 下，参数会被拷贝（非引用传递），槽函数拿到的是副本，原对象修改不影响槽内值
槽函数被调用时，接收对象可能已被销毁
Qt 会自动断开连接，但前提是发送方或接收方对象是 QObject 派生类且正确析构。常见漏点：
- 用
new创建但没设 parent 的临时对象，手动delete后槽仍可能被调用（悬空指针） - Lambda 捕获了局部变量或 this，而对象提前销毁，Lambda 再执行就 crash
- 用
connect返回值判断是否成功（它返回QMetaObject::Connection），但很多人忽略这个 bool 值，连接失败也不报错
稳妥写法：
emit
- 每秒 emit 几百次（如传感器采样）+ QueuedConnection → 主线程事件队列积压，界面卡死
- 解决方案：批量聚合数据，改用单次信号带容器参数（
void dataBatch(const QVector<sample>&)</sample>） - 紧急场景可用
QSignalBlocker临时屏蔽信号，避免连锁响应爆炸 - 调试时打开日志：
QT_LOGGING_RULES="qt.qobject.connections.debug=true"查看连接/断开详情
最常被忽略的一点：信号与槽不是万能胶水。该用信号的地方（解耦、广播、跨线程）坚决用；该直接调用的地方（性能敏感路径、确定调用者/被调用者关系）别硬套。混淆这两者，才是多数“信号不生效”问题的根源。
