VSCode调试C程序核心是可执行文件带-g符号且launch.json中program和miDebuggerPath路径正确；program必须为运行时可访问的绝对路径，如"${fileDirname}/test"，非相对路径或编译输出名。
VSCode 调试 C 程序，核心就两件事：可执行文件带 -g 调试符号，launch.json 里 program 和 miDebuggerPath 指向正确。缺一不可，否则 F5 后直接报错或断点灰色不命中。
launch.json 中 program 字段为什么总指向错误路径
这个字段必须是运行时能真实访问到的可执行文件路径，不是编译命令里的输出名，也不是相对路径 ./a.out。
-
program值推荐用"${fileDirname}/a.out"或"${workspaceFolder}/build/myapp"—— VSCode 在调试前不会自动帮你执行编译，它只负责启动 GDB 加载指定文件 - 如果你手动在终端用
gcc -g test.c -o test编译，program就得写成"${fileDirname}/test"，不能写"./test"（Windows 下尤其容易失败） - 路径中含中文、空格或符号链接未解引用，会导致 GDB 找不到文件；用
file ./a.out验证是否含with debug_info是最直接的判断方式
远程调试时 miDebuggerPath 和 miDebuggerServerAddress 怎么配
远程调试 ≠ 本地启动 gdb，而是本地 VSCode + 远程 gdbserver 协作。VSCode 不会把本地 gdb 传过去，它只连远程的 gdbserver 实例。
- 删掉
miDebuggerPath字段，或设为null；它只在本地调试时起作用，远程模式下无效 - 关键字段是
"miDebuggerServerAddress": "192.168.1.200:2345"，其中 IP 是开发板或服务器地址，端口是gdbserver监听端（如gdbserver :2345 ./myapp） - 确保远程机器已安装
gdbserver（Ubuntu：sudo apt install gdbserver），且防火墙放行对应端口 - 不要在 launch.json 里写
"MIMode": "gdbserver"—— 正确值永远是"gdb"，协议层由 VSCode 自动适配
断点不命中？先检查这三处硬性条件
灰色断点不是 VSCode UI Bug，是底层符号信息缺失或路径错位的明确信号。
- 编译命令没加
-g，或者用了-O2以上优化——-O0 -g是安全组合，-O1已可能导致变量优化消失、单步跳转异常 -
tasks.json的args里漏了-g，或写成了--g（双横线错误）、-g3（无此参数） - 源码被移动过，但可执行文件仍指向旧路径；
readelf -S ./a.out | grep debug有输出，但gdb ./a.out -ex "info sources"显示的源文件路径和当前 workspace 不一致
条件断点怎么写才生效
VSCode 图形界面点右键“Edit Breakpoint”输入的表达式，本质是传给 GDB 的 condition <num> <expr>，语法必须严格符合 GDB 规则。
- 变量名必须在当前作用域可见，不能用宏名或 typedef 别名（如
int32_t x的条件写x == 10，别写int32_t == 10） - 字符串比较用
strcmp(buf, "done") == 0，不能用buf == "done"（地址比较） - 避免在条件里调用函数（如
malloc(1)），GDB 默认禁用函数求值，需先执行set can-use-hw-watchpoints 0和set auto-load safe-path /（不推荐，易崩溃） - 多条件用
&&||，括号必须英文半角，i >= 0 && i < 10可以，i >= 0 and i 会报错
最常被忽略的是：条件断点依赖调试符号完整性和变量生命周期。如果某次单步后变量显示 <optimized out>，那条件断点必然失效——这不是配置问题，是编译选项或代码结构导致的底层限制。
