在 VS Code 中调试 C/c++/rust 程序，关键是正确配置 launch.json、编译时添加 -g（C/C++ 加 -O0）或启用 debug=true（Rust），并确保调试器（GDB/LLDB）路径准确、版本兼容；插件仅提供 ui，核心依赖编译信息、路径映射与权限设置。
在 VS Code 中用 GDB 或 LLDB 调试 C/C++/Rust 程序，核心是配置好 launch.json 并确保调试器和编译产物匹配。重点不是装插件，而是让调试器能正确加载符号、停在源码行、读取变量——这依赖编译选项、路径设置和调试器版本协同。
确保编译时带调试信息
没有调试信息（-g），VS Code 只能看到汇编或无法断点。不同语言写法略有差异：
- C/C++：用
gcc -g -O0 main.c -o main（-O0避免优化导致变量被优化掉、行号错乱） - Rust：默认 debug 模式就带完整调试信息，直接
cargo build即可；若用cargo build --release，需在Cargo.toml中显式加debug = true
安装对应调试器和 VS Code 插件
插件只是 UI 桥梁，真正干活的是本地调试器：
- linux/macOS：系统自带
gdb或lldb，推荐用lldb（尤其 Rust，兼容性更好） - windows：用
gdb推荐 MinGW-w64（含x86_64-w64-mingw32-gdb），或 WSL 内用原生gdb/lldb - VS Code 插件：C/C++（microsoft 官方，支持 GDB/LLDB）、CodeLLDB（纯 LLDB，Rust 用户首选，自动识别
cargo输出）
正确配置 launch.json
不要依赖自动生成的模板，关键字段要按实际路径和调试器类型填准：
立即学习“C++免费学习笔记（深入）”；
-
program：必须是带调试信息的可执行文件绝对路径（如"${workspaceFolder}/target/debug/myapp"） -
miDebuggerPath（GDB）或lldbExecutable（LLDB）：显式指定调试器路径，避免 VS Code 找错版本（例如 macOS 自带 lldb 版本旧，可填/opt/homebrew/bin/lldb） -
externalConsole：设为true才能在独立终端中看到printf或用户输入 -
env或envFile：需要环境变量时（如LD_LIBRARY_PATH），别漏掉
常见卡点与绕过方法
断不进去、变量显示 <optimized out></optimized>、跳转错行？大概率是下面几个地方没对齐：
- 编译路径 vs 源码路径不一致 → 在
launch.json加sourceFileMap映射（例如 WSL 开发时 Windows 路径映射到 Linux 路径） - Rust 使用
cargo run启动 → 不要用它调试，直接调试生成的二进制（target/debug/myapp），否则会多一层 wrapper 进程 - LLDB 在 macos 上无法 attach 到进程 → 检查是否已执行
sudo DevToolsSecurity -enable并给 Terminal 全盘访问权限 - GDB 提示
ptrace: Operation not permitted（Linux）→ 运行echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
基本上就这些。调通一次后，同一项目后续基本不用再动配置。关键是编译、调试器、launch.json 三者对上号，而不是堆插件或改一堆高级选项。