VSCode如何在WSL中运行和调试代码
使用Remote-WSL插件,在WSL终端执行code.或通过WSL:NewWindow打开项目。项目必须置于/home/xxx,避免/mnt/c因内核挂载策略导致调试失败。调试器如gdb需在WSL内安装配置,Python/Go/.NET扩展需在WSL环境安装对应工具。注意检查/etc/resolv.conf避免符号加载超时。
先说个关键前提: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…”的情况,先检查这个文件的内容是否异常。


































