VSCode如何在WSL中运行和调试代码

先说个关键前提：Remote-WSL插件是VSCode连接WSL2的唯一官方方案。要么在WSL终端里敲code .启动，要么通过WSL: New Window打开/home路径——就这么两个入口。所有工具链、调试器、路径配置都得严格限定在WSL2内，/mnt/c和SSH配置统统禁用。

说到底，正确的起点就一个：直接用 Remote - WSL 插件打开项目目录。VSCode后端进程跑在WSL里，Windows界面只是前端。别想着手动配SSH，也别改 settings.json 试图“连过去”——那条路根本走不通。

装对插件，别碰 SSH 配置

Remote - WSL 是微软官方出品，插件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…”的情况，先检查这个文件的内容是否异常。