Call Stack 窗口为空是因调试信息未生成或未加载成功；需确保构建为 Debug 模式、编译含 -g 符号、调试器正确加载未 strip 的二进制，且无内联/尾调用等优化干扰。
Call Stack 窗口为空，不是 Qt Creator 坏了，而是调试信息根本没生成或没加载成功。只要构建配置、编译选项、调试器三者对齐，
Call Stack 就能正常显示完整调用链。
确认当前是 Debug 构建模式
Qt Creator 的
Call Stack 严重依赖未优化的调试符号。Release 模式下默认关闭
-g、启用
-O2 或更高，函数会被内联，栈帧被破坏，堆栈必然断裂或只剩
main。
- 左侧边栏切换到 Projects 模式
- 检查当前 Kit 下的
Build configuration 是否为 Debug（不是 Release 或 RelWithDebInfo）
- 若已改过配置，必须执行
Clean → Rebuild，仅 Build 不会重生成调试符号
- 使用 CMake 项目时，额外确认
CMAKE_BUILD_TYPE 在 Kit 中设为 Debug，否则 cmake 会忽略 -g
验证调试符号是否真实存在
即使选了 Debug，也可能因编译器参数缺失或构建系统干扰导致符号未嵌入。
- Linux/macOS：终端运行
file your_executable，输出含 not stripped 才安全；再跑 readelf -S your_executable | grep debug，应看到多个 .debug_* 节区
- Windows：用
dumpbin /headers your_executable.exe，检查是否有 debug 相关节区（如 .debug$S）
- 常见漏点：
strip 命令误加在 install 步骤；CMakeLists.txt 里手动写了 set(CMAKE_STRIP ...)；qmake 的 CONFIG += release 覆盖了 debug 配置
确保调试器正确加载符号
GDB/LLDB 启动后需主动加载符号，尤其在附加到运行进程或跨平台调试时容易失败。
- 断点命中后，打开
Debugger > Views > Modules 窗口，查看你的可执行文件状态是否为 Loaded，且 Symbols 列显示 Yes
- 若显示
No，右键该模块 → Load Symbols，或检查 Debugger > Settings > Additional Startup Commands 是否误加了 set auto-solib-add off
- macOS 上 LLDB 默认不自动加载 dylib 符号，可在启动命令中加
settings set target.auto-load-script-transfer-enabled true
- Qt Creator 有时缓存旧调试器状态，重启 IDE + 重新 attach 是最快验证方式
堆栈显示异常但符号存在？查内联与尾调用
符号存在、模块已加载，却仍只看到 1–2 层调用，大概率是编译器优化残留或语言特性干扰。
-
gcc/clang 即使在 Debug 模式下，若源码含 [[gnu::always_inline]] 或 inline 关键字，仍可能强制内联——移除这些修饰再试
- 函数末尾的
return func(...) 可能触发尾调用优化（尤其 GCC），用 -fno-tail-call 禁用
- Qt 的信号槽连接若用
Qt::DirectConnection 且目标函数简单，调试器可能将其“扁平化”显示；换用 Qt::QueuedConnection 可还原调用层次
- 某些模板实例化深度过大时，GDB 解析符号极慢甚至跳过，此时
Call Stack 显示不全属正常行为，非配置错误
真正卡住的往往不是操作步骤，而是构建产物和调试器之间的符号信任链——它需要 Debug 配置、未 strip 的二进制、正确加载的模块、以及未被优化抹除的栈帧四者同时成立。少一个环节，
Call Stack 就只剩空壳。
