最直接有效的方式是用 next（跳过函数）或 step（进入函数）逐行执行，前提是编译时加 -g 且禁用优化；否则将无法查看源码或行为异常。
用 GDB 单步执行并逐行查看代码
最直接有效的方式是用 gdb 启动程序后，用 next（跳过函数）或 step（进入函数）命令逐行执行。前提是编译时加了 -g 调试信息，否则 GDB 看不到源码行。
常见错误现象：运行 gdb ./a.out 后输入 next 却提示 Single stepping until exit from function... 或直接跳过整段——大概率是没加 -g 编译，或者优化等级太高（如 -O2）导致行号信息丢失或代码被重排。
- 编译必须带
-g：例如g++ -g -o main main.cpp - 避免高优化：调试时禁用优化，即不加
-O1及以上；若必须带-O0最安全 - 启动后先用
list确认能否看到源码，再用break main下断点，run启动 -
next执行当前行，遇到函数调用不进去；step会进入函数内部——别混淆这两个行为
VS Code + C/C++ 扩展的图形化单步调试
如果你习惯图形界面，VS Code 配合 C/C++ 扩展可以点鼠标完成逐行执行，本质还是调用 gdb，但隐藏了命令行操作。
容易踩的坑：配置 launch.json 时 miDebuggerPath 指向错误的 gdb（比如 macOS 上默认是 lldb），或 program 路径写错导致“无法启动”；还有常见的是没在 args 里补全命令行参数，结果程序一运行就因 argc == 1 提前退出，误以为“没走起来”。
- 确保
launch.json中configuration的type是cppdbg，不是cppvsdbg（Windows VS 专用） -
preLaunchTask推荐设为build，并确认tasks.json里编译命令含-g - F10 是
next，F11 是step，注意看左下角“当前执行行”高亮是否真的在你预期的位置
没有调试器时用 std::cout 打桩输出
当环境受限（如嵌入式交叉编译、容器内无 gdb）、或只是想快速确认某几行是否执行到，std::cout 仍是最朴素有效的手段。
性能影响常被低估：频繁输出会严重拖慢执行，尤其在循环里；更隐蔽的问题是 std::cout 默认行缓冲，如果程序崩溃在某次输出之后但还没换行，那条日志可能根本刷不出来——看着像“卡在了上一行”。
- 关键位置用
std::cerr替代std::cout，它默认不缓冲，更可靠 - 加
或 <code> 强制刷新，避免日志丢失 - 用宏封装，方便批量开关：例如
#define DEBUG_LOG(x) std::cerr
为什么 printf 在某些情况下比 std::cout 更“稳”
在 C++ 程序启动早期（比如全局对象构造阶段）、或信号处理函数中，std::cout 可能尚未初始化或处于不一致状态，此时调用会触发未定义行为，甚至直接 crash；而 printf 是 C 运行时底层函数，初始化更早、更轻量。
这不是推荐回归 C 风格，而是提醒：当你的“逐行查看”需求出现在 main() 之前（如全局变量的构造函数），或需要在 SIGSEGV 处理器里打点，printf 是更可信赖的选择。
- 必须用
printf时，记得包含<cstdio></cstdio>，不要只靠<iostream></iostream>隐式引入 -
printf不支持 C++ 类型自动推导，对std::string要写str.c_str()，对std::vector等需手动展开 - 多线程环境下，
printf和std::cout都不是线程安全的——除非你自己加锁，否则混用可能导致输出乱序或截断
-g 没生效，看到的永远是汇编和问号。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
