先确认已打开.cpp或.c文件，否则VS Code无法识别C++环境并静默失败；必须先打开源码再执行Debug: Open launch.json，且需确保已安装gdb/lldb、tasks.json正确生成带-g调试信息的可执行文件、program路径与preLaunchTask任务名严格匹配。
launch.json 生成失败？先确认有没有打开 .cpp 文件
VS Code 不会在空文件夹或未打开源码时主动识别 C++ 环境，Debug: Open launch.json 命令必须在已打开 .cpp 或 .c 文件的前提下执行。否则它不知道该推荐 GDB 还是 LLDB 模板，直接静默失败。
- 常见错误：新建文件夹 → 直接点调试图标 → 点“创建 launch.json” → 选 C++ → 报错或无反应
- 正确流程：先新建/打开一个
main.cpp，再按Ctrl+Shift+P（macOS 是Cmd+Shift+P），输入并选中Debug: Open launch.json - 如果系统没装调试器（如
gdb或lldb），VS Code 也不会报错，只是跳过配置引导——务必提前验证gdb --version或lldb --version
program 路径写错，断点永远灰掉
program 字段必须指向**已存在且带调试信息**的可执行文件。光写路径模板不等于文件真被生成了，断点失效绝大多数是因为这个。
-
"program": "${workspaceFolder}/${fileBasenameNoExtension}.exe"（Windows）或"${workspaceFolder}/${fileBasenameNoExtension}"（Linux/macOS）是常用写法，但前提是tasks.json真把输出文件放到了这里 - 必须确保
preLaunchTask对应的任务名和tasks.json中的label完全一致（包括大小写、空格） - 编译命令里漏了
-g参数，生成的二进制没有调试符号，launch.json就算路径全对，断点也会变灰 - Windows 下若用 MinGW，
program后缀必须是.exe；Linux/macOS 则不能加，否则找不到文件
miDebuggerPath 不填或填错，调试器根本启动不了
miDebuggerPath 不是可选项，它是 VS Code 启动调试器的唯一入口。填错、路径不存在、权限不足，都会导致点击调试后无响应或报 “Unable to start debugging”。
- Linux/macOS：通常填
"gdb"或"lldb"即可，前提是它们在PATH中；验证方式：终端运行which gdb - Windows + MinGW：必须写绝对路径，如
"C:\mingw64\bin\gdb.exe"；反斜杠要双写，单写会解析失败 - macOS 若用 Homebrew 装的 llvm，
miDebuggerPath应为/opt/homebrew/bin/lldb（Apple Silicon）或/usr/local/bin/lldb（Intel），不是系统自带的lldb - 别依赖
MIMode自动推导——"MIMode": "gdb"和"miDebuggerPath": "lldb"混搭会导致静默失败
externalConsole 设为 false 却读不到输入？程序一闪而过
当 externalConsole 为 false（默认值）时，VS Code 使用集成终端运行程序。但如果程序有 std::cin 或等待用户输入，终端可能在执行完就关闭，导致你看不到输出或输不了内容。
立即学习“C++免费学习笔记（深入）”；
- 临时解决：把
"externalConsole": true，让程序在独立窗口运行，输入输出都可见 - 长期方案：保持
false，但在代码末尾加std::cin.get();或system("pause");（仅 Windows）来阻塞退出 - 注意：
externalConsole: true在 macOS/Linux 上会弹出 Terminal.app 或 gnome-terminal，可能因沙盒或权限问题打不开——此时需检查系统终端是否可被外部调用
launch.json 写得完全符合文档，只要 gdb 找不到可执行文件，或者那个文件没编译出调试信息，调试就只会停在黑屏或跳过断点。 
