Dev-C++断点失效主因是未生成调试信息、优化级别非零、断点设在空行/注释/预处理行；需勾选Generate debugging information、设-O0、打在有效代码行。
断点调试不是“高级功能”，而是你写完 main() 后就该立刻用上的基本动作。它不依赖 IDE 多强大，只取决于你是否在编译时保留了调试信息、是否理解“断点停在哪一行”这个关键细节。
Dev-C++ 里断点打不上？先检查这三件事
很多人按了 F4 或点了行号左侧，红色圆点没出现，或者出现了但运行时不暂停——大概率是以下问题：
- 编译器没生成调试信息：进
Tools → Compiler Options，必须勾选Generate debugging information - 优化级别不是
None：哪怕只勾了-O1，gdb就可能把变量优化掉、跳过断点行，导致“断点灰色”或“直接跑过” - 断点打在了无效位置：比如空行、注释行、预处理指令行（
#include、#define），这些地方没有对应机器码，点不亮
VSCode 中断点显示为空心圆？别急着重装插件
空心圆（◌）不是 bug，是 VSCode 明确告诉你：“这行代码没被编译进去”。常见原因和解法：
-
launch.json里program路径指向了旧的可执行文件，而你刚改了源码但没重新编译——删掉旧.exe或./a.out，再按 F5 -
tasks.json没配-g参数：gcc/clang 编译命令里缺了-g，生成的二进制就没有调试符号，断点必然失效 -
c_cpp_properties.json的includePath错了，导致头文件解析失败，某些内联函数或模板实例化被跳过，断点所在行实际未参与编译
什么时候该用条件断点而不是普通断点？
当你面对一个循环执行 10000 次的 for，只想看第 9999 次时 data[i] 的值，手动按 F8 一千次不现实。这时要靠条件断点：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- Dev-C++ 不支持原生条件断点，得靠临时加
if (i == 9999) __debugbreak();配合编译调试版 - VSCode 或 Qt Creator 可右键断点 → Edit Breakpoint → 输入
i == 9999；GDB 命令行用break main.cpp:42 if i==9999 - 注意：条件表达式里不能用未初始化的变量，也不能调用复杂函数（比如
strlen()），否则断点可能不触发或崩溃
单步执行时“跳进函数”还是“跳过函数”？看这行有没有花括号
新手常困惑 F7（Step Into）和 F8（Step Over）的区别。最直白的判断依据是当前行是否调用了你自己写的、有函数体的函数：
- 如果这行是
printf("hello");或std::cout ，F7 通常不会进入实现（除非你装了 libc++ 源码并配置了符号路径），F8 和 F7 行为几乎一样 - 如果这行是
process_data(arr, len);，且process_data是你自己定义的函数（.cpp 文件里有{ ... }），F7 会跳转到函数第一行，F8 则直接执行完该函数再停 - 光标停在
return上按 F7，会返回上一层调用处；停在}上按 F7，行为不确定——有些调试器会跳到调用点下一行，有些会卡住，建议避免在这种位置单步
真正容易被忽略的，是“断点生效的前提从来不是 IDE 图形界面多漂亮，而是你手动生成的可执行文件里有没有 .debug_* 段”。哪怕用记事本写代码、命令行编译，只要加了 -g，就能用 GDB 打断点。图形界面只是帮你点了几下鼠标，背后全是同一套调试信息在起作用。
