VSCode的cppdbg调试器不自带调试逻辑，仅调用系统已安装的gdb或lldb；必须先安装对应调试器并正确配置miDebuggerPath路径，且tasks.json中编译命令须含-g、禁用-O2，否则断点无效、变量不可见。
VSCode 调试器不是独立程序，而是调用系统已安装的 gdb 或 lldb
VSCode 的 cppdbg 类型调试器本身不包含任何调试逻辑，它只是个前端封装：Windows 下默认找 gdb.exe，macOS 下默认走 lldb（通过 cppvsdbg 或 lldb 类型适配），Linux 下则依赖系统级 gdb。你改 launch.json 里的 miDebuggerPath，只是告诉 VSCode “去哪找那个可执行文件”，而不是“装一个新调试器”。所以第一步永远是：先在系统里装好能跑起来的调试器，再配路径。
Windows 必须用 MinGW-w64 的 gdb.exe，别碰 MSVC 的 cl.exe + cv2pdb
VSCode 的 C/C++ 扩展对 MSVC 工具链（cl.exe）的符号解析和断点命中支持极不稳定，常见现象包括断点灰色不可用、变量显示为 <optimized out>、调试器卡死在加载 PDB 阶段。MinGW-w64（推荐通过 MSYS2 安装）提供完整 DWARF 调试信息支持，且 gdb.exe 命名规范、路径清晰：
pacman -S mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-gdb- 把
C:\msys64\ucrt64\bin加进系统PATH（重启终端生效） -
c_cpp_properties.json中compilerPath设为"C:/msys64/ucrt64/bin/g++.exe"（注意正斜杠） -
launch.json中miDebuggerPath必须写全路径+后缀："C:/msys64/ucrt64/bin/gdb.exe"，漏掉.exe就会报 “executable not found”
macOS 上 lldb 是唯一可靠选择，gdb 基本不可用
macOS 自带 lldb，只要装了 Xcode Command Line Tools（xcode-select --install）就直接可用；而 Homebrew 安装的 gdb 需手动签名、绕过 SIP、每次更新系统都可能失效，实际调试中常报 Unable to find process plug-in for process 或直接拒绝 attach。VSCode 在 macOS 上应明确禁用 gdb 路径配置：
-
c_cpp_properties.json中compilerPath设为"/usr/bin/clang++" -
launch.json中不要填miDebuggerPath，而是靠osx分支指定"MIMode": "lldb" - 确保
tasks.json编译命令含-g且无-O2，否则lldb读不到有效调试符号
Linux 下 gdb 安装简单但调试体验取决于符号包
Ubuntu/Debian 直接 sudo apt install gdb build-essential 就够用，但想看清 STL 容器（如 std::vector 内部数据）、libc 函数栈帧，必须额外装符号包：
-
sudo apt install libstdc++6-12-dbg（对应 GCC 版本号） sudo apt install libc6-dbg- 验证是否生效：在
gdb中print std::vector<int>{1,2,3}，能展开看到_M_impl才算成功 -
launch.json中miDebuggerPath可设为"/usr/bin/gdb"，但更推荐留空——VSCode 会自动 fallback 到 PATH 中第一个gdb
真正容易被忽略的是：所有平台下，tasks.json 编译任务若没加 -g 或误启 -O2，哪怕调试器路径全对，也会导致断点无效、变量不可见——这不是配置问题，是编译器根本没生成可调试信息。
