断点变灰提示“breakpoint set but not yet bound”是因为调试器未获取有效符号信息或未正确attach进程；需检查编译是否含-g且禁用优化（如g++ -g -o0）、program路径是否准确指向带符号的可执行文件，并确认debug console中出现“loaded symbols”日志。
断点打上了，F5一按程序直接跑完，变量没看到、调用栈没进、红点变灰写着“Breakpoint set but not yet bound”——这不是 VS Code 坏了，是调试链路中某个环节没对齐。核心问题就一个：gdb 或 lldb 没拿到有效的符号信息，或者根本没 attach 到执行你代码的那个进程上。
编译时没带调试信息或优化干扰了断点映射
没有 -g，VS Code 就像蒙眼找人；开了 -O2 以上，编译器可能把函数内联、删掉空行、重排逻辑，导致源码行号和机器指令脱节。
-
g++ -g -O0 main.cpp -o main是最安全的组合，-O0必须显式写，别依赖默认值 - Clang 用户加
-grecord-gcc-switches，否则某些调试器（如 VS Code 的 C/C++ 插件）可能读不到完整编译参数 - 验证符号是否真在二进制里：
readelf -w ./main | head -5（Linux/macOS）或dumpbin /headers main.exe | findstr "debug"（Windows + MSVC） - 如果输出为空或报错
No debug data，说明编译阶段就失败了，回头检查tasks.json的args字段是否漏了-g
launch.json 中 program 路径错配或未生效
program 字段不是“随便指向一个可执行文件”，它必须和你实际运行/调试的目标完全一致——路径要绝对、文件要存在、时间戳不能比源码还旧。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 别用
./main这种相对路径，换成${workspaceFolder}/main或完整路径，尤其在多根工作区下，相对路径会崩 - 确认
program指向的文件确实存在：ls -l ${workspaceFolder}/main，不存在就说明preLaunchTask没跑成功或输出路径不对 - 如果用了 CMake，
program应该是${workspaceFolder}/build/myapp，而不是${fileDirname}/${fileBasenameNoExtension}—— 后者只适用于单文件快速测试 -
stopAtEntry设为true可强制停在main入口，方便确认调试器是否真的启动了
Apollo/cyber 等框架下断点不绑定的特殊原因
你的代码不是直接跑在 main() 里，而是被 mainboard 动态加载的 component；VS Code 默认 launch 模式只会 attach 到你手动启动的进程，而真正执行逻辑的是它 fork 出来的子进程。
- 先执行
ps -ef | grep mainboard，找到正在运行的 Apollo 主进程 PID - 把
launch.json的request改成attach，填入对应 PID，并设置processId字段 - 或者用
cyber_monitor查看当前活跃的 channel 和 node，再用gdb -p PID手动 attach 验证能否停住 - 条件断点更可靠：
if (some_flag == true)，避免在初始化阶段就被跳过
最容易被忽略的一点：Mac 上换系统后 Xcode 命令行工具更新了，但 lldb 插件可能还在用旧版 runtime；Windows 上 MinGW 的 gdb.exe 和 gdb-python.exe 版本不匹配也会静默失败。不要只看红点有没有打上，要看 DEBUG CONSOLE 里有没有 Loaded symbols for … 这类日志——没这句，基本等于没连上符号表。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
