Remote-WSL插件是VSCode连接WSL2的唯一官方方案，必须通过code .在WSL终端中启动或WSL: New Window打开/home路径，所有工具链、调试器、路径配置均需严格限定在WSL2内，禁用/mnt/c和SSH配置。
直接用 Remote - WSL 插件打开项目目录，VSCode 后端进程就跑在 WSL 里，Windows 界面只是前端——这才是正确起点。别手动配 SSH、别改 settings.json 试图“连过去”，那条路根本走不通。
装对插件，别碰 SSH 配置
Remote - WSL（Microsoft 官方出品，ID 是 ms-vscode-remote.remote-wsl）是唯一正路。它不走网络协议，而是通过本地 Unix socket 和 WSL 通信，快且稳。
- 卸载所有标着 “WSL SSH”、“Remote SSH for WSL” 的第三方插件，它们会干扰或覆盖官方行为
- 确保 VSCode 是 1.35+ 版本；旧版即使装了插件，
code .也不会触发 WSL 模式 - 安装后不用额外配置——首次在 WSL 终端中执行
code .，它会自动下载并启动 VSCode Server
项目必须放在 /home/xxx，别放 /mnt/c
WSL 对 /mnt/c 下的文件默认禁用执行权限，且调试器加载符号表失败率极高。这不是权限问题，是内核挂载策略导致的硬限制。
- 把代码复制进
/home/yourname/project，再用cd /home/yourname/project && code .打开 - 如果已在
/mnt/c下编辑过，file app输出若不含with debug_info，说明符号丢失，重编译时加-g -
launch.json中所有路径（program、cwd、env.LD_LIBRARY_PATH）都得写 WSL 路径，C:\work\app这类 Windows 路径在这里完全无效
调试 C/C++ 时，gdb 要在 WSL 里装，不是 Windows
VSCode 调试器实际调用的是 WSL 环境里的 gdb，所以依赖、版本、路径全得按 Linux 视角来。
- 运行
wsl -l -v确认发行版状态为Running；Ubuntu 默认镜像精简，常缺gdb和build-essential - 在 WSL 终端中执行：
sudo apt update && sudo apt install -y build-essential gdb -
launch.json中设"externalConsole": false，否则调试时弹独立终端，输入/输出无法捕获 - 若用交叉工具链，
MIMode字段要明确指向对应gdb，比如/usr/bin/arm-linux-gnueabihf-gdb
Python/Go/.NET 调试的关键差异点
语言扩展的行为差异比想象中大：Python 和 Go 插件需在 WSL 环境里安装（右下角弹窗选 “Install on WSL”），而 .NET 在 VS Code 里靠 Remote - WSL 自动识别，但前提是 WSL 发行版已预装 .NET SDK。
- Python：断点设在
.py文件上后按F5，选 “Python File”；确保 WSL 中python3 -m pip list | grep debugpy有输出 - Go：
dlv必须在 WSL 里安装（go install github.com/go-delve/delve/cmd/dlv@latest），Windows 上的 dlv 不起作用 - .NET：VS Code 不支持直接调试 WSL 内核，但能调试用户态 .NET 应用；若
dotnet --list-sdks在 WSL 中无输出，需手动安装 SDK
最常被忽略的一点：WSL 的 /etc/resolv.conf 可能被 Windows DNS 策略覆盖，导致调试器拉取符号服务器超时；遇到卡在 “Loading symbols…” 时，先检查该文件内容是否异常。
