调试器卡在“正在启动调试器”通常是因program路径不存在、调试器配置错误或环境缺失。需优先检查program绝对路径、miDebuggerPath匹配性、preLaunchTask编译是否成功，并启用"stopAtEntry": true快速定位卡点。
调试器卡在“正在启动调试器”通常是 launch.json 配置或环境没到位
VSCode 的 C++ 调试依赖 cppvsdbg（Windows）或 lldb（macOS/Linux）后端，但真正卡住的往往不是调试器本身，而是它根本没开始运行——因为 VSCode 还在等一个可执行文件、符号文件、或调试器路径。常见现象是左下角显示“正在启动调试器”，几秒后无响应，控制台里也看不到 gdb 或 lldb 进程起来。
检查点优先级：先确认 program 路径是否真实存在且已编译；再看 miDebuggerPath 或 MIMode 是否与当前平台匹配；最后确认 preLaunchTask 有没有成功触发编译。
-
program必须是绝对路径，相对路径（如"./build/main"）在某些工作区配置下会失效，建议用${workspaceFolder}/build/main - Windows 上用
cppvsdbg时，miDebuggerPath不需要填；但若手动切到gdb，就必须指定完整路径（如C:/msys64/mingw64/bin/gdb.exe），且该路径不能含中文或空格 - macOS 上如果装的是 Apple Clang，默认不带
lldb命令行工具，需运行xcode-select --install补全
launch.json 中的 “stopAtEntry”: true 容易被忽略，但它能帮你快速定位卡点
这个配置项会让调试器一加载完就停在 main 函数第一行，而不是等它自己跑起来再断点。如果启用了它，却依然卡住，说明问题出在加载阶段（比如找不到 program、符号表损坏、或调试器进程根本没拉起来）；如果它能停住，那大概率是你原来的断点设置太晚，或者程序启动逻辑里有阻塞。
- 临时加一行
"stopAtEntry": true到launch.json的配置里，保存后重试 F5 - 如果这时能停住，说明调试器通了，回头检查你原断点位置是否在异步回调、子线程或未执行分支里
- 如果仍卡住，打开 VSCode 的“调试控制台”（Debug Console），看有没有类似
Unable to launch program 'xxx': File not found的提示
Windows 下用 MinGW-w64 时，gdb 启动失败常因缺少运行时 DLL
哪怕 miDebuggerPath 指向了正确的 gdb.exe，它也可能静默失败——因为 gdb.exe 依赖同目录下的 libwinpthread-1.dll、libgcc_s_seh-1.dll 等，而 VSCode 启动子进程时不会自动把 MinGW 的 bin 目录加进 PATH。结果就是 gdb 进程一闪而过，VSCode 却一直等它连接。
立即学习“C++免费学习笔记（深入）”；
- 打开终端，手动运行一遍你配置的
gdb.exe路径，看是否报 DLL 找不到错误 - 把 MinGW 的
bin目录（如C:/msys64/mingw64/bin）加进系统 PATH，或在 VSCode 的settings.json里加："terminal.integrated.env.windows": { "PATH": "C:/msys64/mingw64/bin;${env:PATH}" } - 更稳妥的做法：用 VSCode 的
tasks.json编译时显式指定mingw32-make和g++路径，保证编译器和调试器来自同一套工具链
Linux/macOS 下权限或符号缺失会导致调试器连进程都 attach 不上
尤其在 WSL 或 Docker 开发场景中，gdb 默认不允许调试非子进程，且要求可执行文件带调试符号（-g）。没有符号时，VSCode 可能卡在“解析调试信息”阶段；权限不足时，ptrace 被拒，gdb 会直接退出，VSCode 却还在等响应。
- 编译命令必须含
-g（如g++ -g main.cpp -o main），检查file main输出里是否有with debug_info - Linux 上运行
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope临时放开调试限制（仅开发机） - WSL2 中若用 Windows 版 VSCode 远程连接，确保
remote.WSL2扩展已启用，且调试配置里的type是cppdbg，不是cppvsdbg
gdb ./main 的那一瞬间暴露。 
