断点失效主因是构建套件选错、调试符号未生成、python dumper冲突或影子构建目录脏污；需切至debug套件、补全-g/-zi编译选项、关闭cdb的python dumper、彻底清理构建目录。
Debug套件没选对，断点直接失效
断点灰显、程序跑过不停——八成是构建套件选错了。Qt Creator左下角那个下拉框，默认可能就是Release，而Release模式下编译器会把代码内联、删掉空行、重排逻辑，调试器根本找不到你点的那行。
检查方法很简单：Projects → Build & Run → 看当前Kit名称里是否含Debug字样（比如Desktop Qt 6.5.3 MSVC2022 64-bit Debug）。不是就立刻切过去，然后务必执行Build > Clean All再Rebuild All。
- 别信“刚改完就编译”，Qt Creator有时只增量编译，旧目标文件残留会导致符号错位
- 如果用CMake项目，确认
CMAKE_BUILD_TYPE设为Debug，而不是靠Kit自动推断 - qmake项目可在
.pro里加一句：CONFIG += debug，避免Kit配置被覆盖
调试符号没生成，GDB/CDB全瞎眼
即使选了Debug套件，如果编译器没加-g（GCC/Clang）或/Zi（MSVC），生成的可执行文件里就没有行号、变量名这些调试信息，断点自然不生效。
验证方法：Linux/macOS下运行objdump -g your_app | grep DW_TAG；Windows下用dumpbin /headers your_app.exe | findstr "debug"。没输出就说明符号丢了。
- qmake项目在
.pro中补上：QMAKE_CXXFLAGS_DEBUG += -g -O0 - CMake项目在
CMakeLists.txt里确保set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g -O0") - MSVC用户注意：
/Zi必须和/DEBUG链接器选项配对，单加一个没用
CDB调试器卡死或QString显示异常
Windows下用CDB时，一命中断点、QString显示成乱码或<inaccessible></inaccessible>，大概率是Python dumper惹的祸。新版CDB和Qt自带的Python扩展常有兼容问题，尤其在Win11 + VS2022组合下。
解决方式直截了当：Tools > Options > Debugger > CDB → 取消勾选Use Python dumper → 重启Qt Creator。
- 这个选项默认开启，但实际多数项目不需要它——关掉后
QStringQList等基础类型照样能展开，只是少了些高级格式化 - 如果必须用Python dumper（比如要解析自定义类型），得手动指定Python路径，并确保版本匹配（推荐Python 3.9–3.11）
- CDB路径本身也要核对：
Tools > Options > Kits > Debugger里看cdb.exe是否存在且可执行
影子构建目录脏了，源码和二进制对不上
UI文件改了不生效、断点跳到奇怪位置、变量值显示<optimized out></optimized>——这些症状背后，往往是一个积灰的影子构建目录。Qt Creator默认把ui_*.h、目标文件、符号表全塞进去，一旦源码更新而构建目录没清，调试器就拿旧二进制去套新代码。
最稳妥做法：直接在文件管理器里删掉整个构建目录（路径通常显示在Projects > Build Settings > Build directory），再重新qmake或CMake configure。
- 别依赖
Clean按钮——它有时漏删中间文件，尤其是ui_*.h这类由uic生成的头文件 - 如果用了Git，注意构建目录一般已.gitignore，但偶尔会误提交部分文件，导致协作时别人拉代码后直接复现你的“断点失效”
- 想彻底规避？在
Projects > Build Settings里取消勾选Shadow build，让构建直接落在源码同级目录（但需接受杂乱的Makefile和obj文件）
ui_mainwindow.h。问题常藏在“看起来一切正常”的缝隙里——多一次清理，少半天排查。
