刚写完 main() 就该开始调试，而非等崩溃；首次按F8须点“Yes”生成调试信息（即加-g参数），否则F7/F4失效、断点无效，因GDB需符号表定位变量内存地址。
刚写完 main() 就该开始调试，而不是等程序崩了才想起断点。 入门阶段不建立调试习惯，后期靠 printf 硬猜、靠删代码试错，效率会卡在“能跑通”和“真懂了”之间很久。
从第一行代码就启用调试信息
DEVC++ 按 F8 启动调试时弹出“是否生成调试信息”，必须点 Yes。这一步实际是让编译器加 -g 参数，把变量名、行号、函数名这些符号信息塞进可执行文件。没它，F7 单步进去全是汇编，F4 看不到变量值，断点打上去也无效——不是 IDE 坏了，是根本没告诉 GDB “i 对应哪块内存”。
- 每次新建工程后，先检查项目选项里“编译时加入调试信息”是否勾选
- 如果用命令行编译（比如
g++ -o app.exe main.cpp），务必加上-g - 开启
-Wall -Wextra警告，很多逻辑隐患（比如未初始化变量）会在编译期暴露，比运行时调试省力十倍
用断点代替 printf，但别乱打
断点不是越多越好。新手常犯的错是：在每行都点一下，结果程序停得密不透风，反而看不清数据流转。真正有效的断点要打在“状态可能出问题的边界”上：
- 函数入口处：确认参数传进来是不是你预期的值（比如
void foo(int* p)，打在这里能立刻看到p是nullptr还是有效地址） - 循环体首尾：观察迭代变量变化趋势，比如
for (int i = 0; i ，断在 <code>i++后能看到每次递增是否正常 - 条件分支前：比如
if (ptr && ptr->data > 0)，断在if行，用F4看ptr和ptr->data的实时值，比猜“是不是空指针”快得多
单步执行时盯住指针和数组下标
C++ 入门最易踩的坑集中在内存操作：越界、悬空、未初始化。而这些在单步中表现得最直接：
立即学习“C++免费学习笔记（深入）”；
-
F7单步进入函数时，注意看栈帧变化——如果进了某个函数后局部变量全显示<optimized out></optimized>，说明编译器做了优化，回头关掉-O2或打开-O0 - 访问数组如
arr[i]，单步到这一行时，用F4查看i的值和arr的地址，心算arr + i是否落在合法内存范围内 - 对指针做
*p解引用前，务必确认p != nullptr且指向堆/栈上仍有效的内存；DEVC++ 里如果p显示为0x0或一串乱码地址，基本可以判定问题就在这儿
调试时别忽略“看起来正常的值”
很多 bug 不是值错了，而是类型或生命周期不对。比如：
- 一个
std::string变量显示为"hello"，看着没问题，但它底层指向的内存可能已被释放（尤其在函数返回临时对象时） - 整型变量显示
100，但实际是unsigned char类型，参与运算时发生隐式提升，结果溢出却不报错 - 调试器里看到
vector.size()是5，但vector.data()地址为空——说明容器为空或 move 后失效
真正难 debug 的，往往不是红色报错，而是“值对了，但行为不对”。这时候得切到汇编视图（DEVC++ 里按 Ctrl+Alt+D），看实际执行的是哪条指令，才能绕过表象抓本质。
