在WSL环境下进行VSCode插件调试的完整步骤-VSCode-PHP中文网

插件必须安装在wsl中，windows端安装无效；vscode在wsl模式下为“前端windows、后端linux”，语言服务、调试器等均依赖wsl环境变量与path，windows侧插件在wsl窗口中灰显且不可用。

在wsl环境下进行vscode插件调试的完整步骤

插件必须装在WSL里，Windows装了没用

VSCode在WSL模式下实际是“前端在Windows、后端在Linux”运行，所有语言服务、调试器、编译器调用都走WSL的PATH和环境变量。你在Windows侧安装的C/C++、Python、CMake Tools等插件，对WSL窗口完全不可见——它们只会灰显，按钮显示Install in WSL: Ubuntu。

常见错误现象：状态栏左下角显示WSL: Ubuntu，但打开launch.json时提示No debug configuration found；或者按F5报错gdb not found，尽管which gdb在终端里能返回/usr/bin/gdb。

确认当前是WSL上下文：终端提示符应为username@hostname:~$，且uname输出Linux
打开扩展面板（Ctrl+Shift+X），搜索插件名，点击Install in WSL: Ubuntu（不是“Install”）
若已装过本地版，点插件右上角云端图标Install Local Extensions in WSL: Ubuntu一键同步（仅同步兼容插件）
禁用所有非必要本地插件，避免干扰：比如Windows侧的GitLens会抢git命令，导致WSL里git status异常

项目路径必须放在`/home/xxx/`，别放`/mnt/c/`

WSL对/mnt/c/挂载的Windows文件系统有严重限制：不支持inotify（文件变更监听失效）、无完整POSIX权限、符号链接损坏、I/O性能下降5–10倍。这会导致插件功能直接降级甚至崩溃——比如CMake Tools无法自动检测CMakeLists.txt变更，Python扩展找不到venv里的pyd模块。

使用场景：你执行git clone或npm install后发现Permission denied或ENOSPC，基本就是路径错了。

在WSL终端中创建项目：mkdir -p ~/projects/myapp && cd ~/projects/myapp
从这里启动VSCode：code . （注意空格+英文句点）
资源管理器路径应显示为wsl$Ubuntu-22.04homeusernameprojectsmyapp，而非\wsl$Ubuntu-22.04mntc...
已误操作？删掉/mnt/c/xxx下的项目，重新git clone到/home/xxx/再开

`launch.json`里`program`和`miDebuggerPath`必须用WSL路径

即使VSCode连上了WSL，C/C++插件默认仍可能读取Windows注册表或PATH去调用gdb.exe，导致调试器启动失败，报错Unable to start debugging. Cannot launch program或Failed to launch gdb。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

关键参数差异：program不能写C:path o.out，miDebuggerPath不能留空或指向Windows路径。

program：必须是Linux绝对路径，如"${workspaceFolder}/build/app"（确保build/在WSL内生成）
miDebuggerPath：显式指定，如"/usr/bin/gdb"（验证用which gdb）
cwd：设为"${workspaceFolder}"，避免相对路径解析错乱
删掉sourceFileMap字段（旧配置遗留项，WSL 2无需映射）

示例片段：

{
  "name": "(gdb) Launch",
  "type": "cppdbg",
  "request": "launch",
  "program": "${workspaceFolder}/build/hello",
  "miDebuggerPath": "/usr/bin/gdb",
  "args": [],
  "stopAtEntry": false,
  "cwd": "${workspaceFolder}",
  "externalConsole": false,
  "MIMode": "gdb"
}