断点未命中通常因代码未执行而非调试器故障：全局对象所在文件未被引用导致链接器剔除，或worker线程未启动/已退出；应检查链接依赖或线程生命周期。
断点进不去，大概率不是调试器坏了，而是线程根本没执行到你设断点的那行代码——或者压根没走到那个函数体、那个作用域里。
断点打在构造函数或全局对象初始化里，但线程没触发加载
比如你在 Button.cpp 里定义了一个全局对象 A ins;，断点打在这行，却从不命中。原因很直接：这个文件没被任何已加载模块引用，链接器根本没把它拉进最终可执行体，CRT 也就不会扫描它的 .data/.bss 段去调用构造函数。
- 现象：
Manager.cpp里只要实例化一个Button，断点立刻生效 —— 因为这时链接器必须把Button.cpp的 OBJ 拉进来，CRT 才会遍历其构造函数表 - 本质是链接时的“按需加载”行为，不是调试器问题
- 解决办法：强制引用该文件（比如在
main()或Manager构造函数里加一句(void)sizeof(Button);），或改用静态链接（/MT），让所有全局构造逻辑都落到 EXE 里
断点打在 worker 线程函数里，但线程还没启动或已退出
常见于 std::thread 或 boost::thread 场景：你断点设在 worker() 开头，F5 启动后断点灰掉或跳过。这不是断点失效，是线程根本没跑起来。
- 检查线程对象是否还在作用域内：
std::thread t(worker);如果t是局部变量且没join()或detach()，它析构时会调用std::terminate()，线程直接被杀，根本没机会执行 - 确认线程是否真被调度：加一句
std::cout 到函数开头，看输出有没有——没有就说明线程没执行，别怪断点 - VS 调试器默认只挂起主线程，worker 线程可能被系统调度器暂时搁置；切换到“调试 → 窗口 → 线程”手动暂停所有线程再查状态
断点打在条件等待或 sleep 之后，但线程卡在阻塞点没往下走
比如断点设在 cv.wait() 后面一行，结果永远不命中。因为线程卡在 wait() 内部，根本没返回，自然到不了下一行。
立即学习“C++免费学习笔记（深入）”；
-
std::condition_variable::wait()、std::this_thread::sleep_for()、mutex.lock()都是中断点（interrupt point），线程在此处可被中断，但也意味着它会长时间停在这里 - 别在阻塞调用后第一行打断点指望“马上停住”，先确认唤醒逻辑是否发出信号、超时是否设置合理、锁是否被其他线程持有
- 想验证线程是否真卡住？在
wait()前加日志 + 在调试窗口里看线程堆栈，如果栈顶是NtWaitForSingleObject或pthread_cond_wait，那就是等信号没等到
优化级别和调试符号不匹配导致源码映射失败
Release 模式下打的断点，在 Debug 配置里跑当然不命中；反过来，Debug 编译但开了 /O2，也可能因内联、死代码消除让断点对应不到实际指令。
- 确认当前构建配置：VS 右下角状态栏看是 “Debug” 还是 “Release”，CLion 看 Build Configuration，命令行看 CMake
CMAKE_BUILD_TYPE - 确保生成了调试符号：
/Zi（MSVC）或-g（GCC/Clang），且 PDB 或 DWARF 文件跟二进制在同一目录 - 禁用优化：
/Od（MSVC）或-O0（GCC/Clang）——多线程调试时尤其重要，否则变量值、执行流都会失真
最麻烦的情况是：断点看起来“进了”，但变量值不对、单步跳转诡异、甚至堆栈显示错乱——那基本是优化或符号错位导致的假象。这时候别纠结断点，先关优化、清构建、重生成，再动手。
