必须用 debug 版 qt 源码编译环境才能调试信号槽内部，因官方 release 包不含调试符号，无法进入 qmetaobject::activate 等核心函数；需编译 debug qt、关联源码、配置 kit 三步缺一不可。
能直接调试，但必须用 Debug 版 Qt 源码编译环境，否则断点进不去 QMetaObject::activate 或 qt_metacall 等核心函数。
为什么普通 Qt 安装包没法调试信号槽内部
预编译的 Qt（比如 online installer 装的）默认不含调试符号，connect、emit 后的调用链全是黑盒。你点进去看到的只是汇编或“no debug info”提示，根本看不到 QMetaObjectPrivate::slotCall 怎么分发参数、QConnectionList 如何遍历接收者。
- Qt 官方不提供带完整调试符号的 release 包，这是设计使然
- 即使启用了
-debug选项安装，若没指定源码路径，QtCreator 仍找不到 .cpp 对应行号 -
Q_OBJECT宏展开的 moc 文件虽在项目里，但真正执行时跳转的是 Qt 动态库里的实现
必须做的三件事：编译 Debug Qt + 关联源码 + 配置 Kit
缺一不可，顺序不能错：
- 用
./configure -debug -opensource -prefix /opt/qt-debug -nomake tests编译 Qt 源码（注意路径别含空格） - 在 QtCreator 的 工具 → 选项 → Qt Versions 中添加新 Qt 版本，路径指向
/opt/qt-debug/bin/qmake - 在 Kits 里新建 kit，Qt version 选刚配的，Debugger 选系统自带的 gdb/lldb，Source paths 必须填你解压的 Qt 源码根目录（如
/home/user/qt-everywhere-src-6.7.2）
验证是否生效：在任意 connect 行打条件断点，F7 进入后，如果能看到 qobject.cpp 里的 connectImpl 函数体，说明成了。
调试时重点盯哪几个函数
信号触发后实际走的是 Qt 元对象系统的硬编码路径，不是你写的槽函数第一行：
-
QMetaObject::activate：所有信号发射的统一入口，看 sender、signal_index、argv 是否符合预期 -
QMetaMethod::invoke：当连接类型是Qt::DirectConnection时，这里会直接 call 槽函数 -
QMetaObjectPrivate::slotCall：处理参数转发，检查argv[0]（返回值）、argv[1]（第一个参数）内存布局是否对齐 -
QObjectPrivate::connectImpl：断点设在这里，能看清 connection 是存进connectionLists还是connectedSignals，排查漏连/重复连
注意：emit mySignal() 本身不进函数——它被 MOC 展开成对 QMetaObject::activate 的裸 call，所以断点要设在 activate，而不是 emit 行。
容易忽略的坑：Lambda 槽和 queued connection
用 Lambda 写槽函数时，调试器可能显示为 ??? 或匿名函数地址，因为 MOC 不生成符号名；而 Qt::QueuedConnection 会让调用跳到事件循环，断点停在 QMetaCallEvent::placeMetaCall 而非你的槽里。
- Lambda 槽无法单步进函数体，建议临时改用命名槽函数定位逻辑
- queued 场景下，必须在
QEventLoop::exec或QCoreApplication::processEvents处设断点，否则会错过槽执行时机 - 跨线程信号（比如 worker thread emit 给 GUI thread）必然走 queued，此时
QThread::currentThread()在 activate 里是 sender 线程，到 slotCall 里才切到 receiver 线程
真要搞清信号怎么跨线程投递，得从 QMetaObject::activate 跟到 QCoreApplicationPrivate::sendPostedEvents，中间隔着 event queue 和 thread data 查找——这一步最容易卡住，因为调试器默认不加载 Qt 库的调试符号，必须确认 Source paths 设置正确且源码版本与库完全匹配。
