必须在wsl终端中执行code .才能真正接入wsl：启动上下文决定环境，状态栏显示“wsl: ubuntu”为唯一可信凭证，项目须置于/mnt/c外的原生路径（如/home/user/），否则chmod、git hooks、调试器等功能异常。

VSCode 在 WSL 下运行代码不是“替代方案”，而是 Windows 开发者当前最省力、最稳定、最接近原生 Linux 体验的落地路径。

它绕开了虚拟机资源争抢、双系统重启、文件同步延迟这些老问题，但前提是 WSL 环境本身得稳，VSCode 的远程连接不能掉链子。下面几个关键点，直接决定你今天能不能顺手跑起一个 g++ 或 python3 脚本。

WSL 发行版必须能独立执行命令，否则 VSCode 连不上

很多卡在 “Remote-WSL: Installing VS Code Server” 卡住的人，其实根本没检查过发行版基础能力是否完整：

windows-shell-syntax

在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……

下载

• wsl --list --verbose 看状态是不是 Running，不是就先 wsl --shutdown 再启动
• 进发行版终端，确认 which curl、which wget、which tar 都有输出——缺任何一个，VSCode 启动 server 都会失败
• Ubuntu/Debian 用户务必先跑：sudo apt-get update && sudo apt-get install -y wget ca-certificates gnupg2，否则 HTTPS 下载校验会挂
• 别用精简版或自定义镜像（比如某些国产发行版），优先选 Microsoft Store 里的 Ubuntu 22.04/24.04

VSCode 必须装对扩展，且不能混用 Remote 插件

VSCode 本地安装的插件不会自动同步到 WSL；而 Remote-WSL 扩展本身不包含调试器、语言服务器等核心能力，靠的是按需加载：

• 只装 Remote - WSL（ID：ms-vscode-remote.remote-wsl），别同时装 Remote - SSH 或 Dev Containers，它们会抢 code . 的解析权
• 打开 WSL 文件夹后，右下角状态栏会显示 WSL: Ubuntu-22.04，点击它可切换默认发行版，避免误开 Windows 版本的 VSCode
• 首次打开 WSL 项目时，VSCode 会自动下载 vscode-server 到 ~/.vscode-server，这个目录不能被 chmod 700 锁死，否则后续更新失败
• 如果反复提示 “Failed to fetch”, 检查 WSL 里是否设置了全局 http_proxy —— ALL_PROXY 会影响 VSCode 自动下载，建议只在需要时临时启用

代码运行路径和权限必须匹配，否则报错不告诉你真实原因

VSCode 在 WSL 中编辑的文件，实际执行时走的是 Linux 权限模型。Windows 用户最容易踩的坑是：把项目放在 /mnt/c/Users/xxx/... 下运行，结果遇到权限拒绝或符号链接失效：

• 永远把项目代码放在 WSL 原生路径，例如 ~/projects/hello-cpp，而不是 /mnt/c/Users/xxx/projects
• 在 WSL 终端中执行 ls -l 确认可执行文件有 x 权限，C++ 编译后用 ./a.out 运行，别漏掉 ./
• Python 脚本若依赖相对路径读取配置，确保工作目录是项目根目录，VSCode 的 terminal.integrated.cwd 设置要和 launch.json 的 cwd 一致
• Node.js 项目不要在 /mnt/c/... 下 npm install，会导致 node_modules 权限混乱、symlink 失效，甚至 require() 报 MODULE_NOT_FOUND

真正卡住人的从来不是“怎么装”，而是“为什么装好了却跑不起来”。WSL + VSCode 的组合足够成熟，但它的容错边界很明确：发行版干净、路径原生、权限可控。越早接受这个前提，越少花时间在重装和查日志上。