必须使用 remote - wsl 插件启动 vscode，调试器（如 gdb）运行在 wsl 中，依赖 linux 路径、wsl 内编译的带 debug_info 的二进制、/home 下的项目路径及安装在 wsl 的 c/c++ 扩展。
必须用 Remote - WSL 插件启动 VSCode，否则所有调试配置都会失效。 这不是可选项，是硬性前提——VSCode 调试器（如 gdb）实际运行在 WSL 环境中，它调用的是 /usr/bin/gdb，读取的是 Linux 路径下的符号表，根本无法处理 Windows 路径或 Windows 版本的调试器。
launch.json 中的路径必须全是 WSL 路径
Windows 路径如 C:\work\app 或 /mnt/c/work/app 在 launch.json 里完全无效。调试器会找不到可执行文件，或加载不到 debug info，导致断点灰掉、变量显示 <optimized out></optimized>。
-
program必须指向 WSL 内编译出的二进制，例如"${workspaceFolder}/build/hello"（前提是项目在/home/yourname/project下） -
cwd推荐设为"${workspaceFolder}"，避免相对路径错乱 - 如果程序依赖动态库，
environment里加{"LD_LIBRARY_PATH": "/home/yourname/lib:/usr/local/lib"}，别写C:\lib - 检查符号：在 WSL 终端里运行
file build/hello，输出中必须含with debug_info；若不含，重编译时务必加-g参数
gdb 必须装在 WSL 里，且版本要匹配
Windows 上装的 gdb 对 WSL 调试毫无作用。VSCode 启动调试时，后端进程直接调用 WSL 中的 gdb 二进制，路径由 miDebuggerPath 指定（默认是 /usr/bin/gdb）。
- 运行
wsl -l -v确认发行版状态为Running - 在 WSL 终端执行：
sudo apt update && sudo apt install -y build-essential gdb - 验证：
gdb --version输出应为GNU gdb (Ubuntu ...)，不是 MinGW 或 Cygwin 版本 - 若用交叉工具链（如 ARM），
MIMode字段需配合miDebuggerPath显式指定，例如"miDebuggerPath": "/usr/bin/arm-linux-gnueabihf-gdb"
别碰 /mnt/c，代码必须放在 /home/xxx 下
WSL 对 /mnt/c 下的文件采用特殊挂载策略：默认禁用执行权限、不支持 inotify 监控、符号表加载失败率极高。这不是权限设置问题，是内核级限制，改 chmod 或 chown 都没用。
- 把项目复制进
/home/yourname/myproject，再在 WSL 终端中执行cd /home/yourname/myproject && code . - VSCode 状态栏右下角必须显示
WSL: Ubuntu（或你用的发行版名），而不是SSH或空白 - 终端（
Ctrl + `）里运行pwd，输出应为/home/yourname/myproject，而非/mnt/c/... - 如果已误放在
/mnt/c下编辑过，即使移入/home，也要彻底清理构建产物（rm -rf build/ CMakeFiles/ *.o a.out）并重新编译
最常被忽略的一点：C/C++ 扩展必须点击 “Install in WSL” 安装到远程环境，而不是只装在 Windows 侧。右下角远程指示器变蓝后，再检查 .vscode/extensions 是否存在于 WSL 的 /home/yourname/.vscode-server 下——这里才是调试逻辑真正运行的地方。
