VSCode 可直接通过 Remote - WSL 插件无缝连接 WSL2 作为主力开发环境，无需 SSH；需确保 WSL2 正常运行、插件已安装，并打开 WSL 路径（如 /home/user/project）而非 Windows 路径，避免 /mnt/c/ 引发的权限与性能问题。
VSCode 可以直接连接 WSL 并作为主力开发环境，不需要额外安装远程服务或配置 SSH —— 官方插件 Remote - WSL 已深度集成，只要 WSL 发行版能正常启动，基本开箱即用。
确认 WSL 已正确安装并运行
很多连接失败其实卡在底层环境没就绪。先验证 WSL 是否真正可用，而不是仅“装过”：
- 在 Windows 终端（非 PowerShell 管理员模式）运行
wsl -l -v，确保至少有一个发行版状态为Running - 若显示
WSL2 is not supported，需启用虚拟机平台：dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart，然后重启 - 若发行版卡在
Stopping或启动报错，尝试重置：wsl --shutdown后再wsl进入 - WSL1 不支持部分 VSCode 功能（如调试器挂载、文件监视），推荐升级到 WSL2：
wsl --set-version2
安装 Remote - WSL 插件并打开 WSL 文件系统
这个插件不是“可选”，而是连接 WSL 的唯一官方路径。它会在 Windows 版 VSCode 中自动识别已安装的 WSL 发行版，并接管整个工作区环境：
- 在 VSCode 扩展市场搜索安装
Remote - WSL（发布者 Microsoft） - 安装后，按
Ctrl+Shift+P打开命令面板，输入WSL: New Window—— 这会启动一个**全新 VSCode 窗口**，底部状态栏显示WSL: Ubuntu（或你实际的发行版名） - 不要用
File → Open Folder直接选 Windows 路径（如C:\src\myapp），那样仍走 Windows 环境；应打开 WSL 路径，例如：/home/username/myproject - VSCode 自动在 WSL 中安装 server 组件（
~/.vscode-server），首次打开可能需要几分钟和网络（代理会影响进度）
Windows 和 WSL 文件路径互访的坑
VSCode 在 WSL 模式下默认使用 Linux 根路径，但 Windows 文件仍可通过 /mnt/c/ 访问 —— 这看似方便，实则极易引发权限、性能和工具链问题：
-
/mnt/c/下的文件由 Windows NTFS 驱动挂载，不支持 Linux 文件权限（chmod无效）、符号链接受限、inotify监听极不稳定（导致 webpack/vite 热更新失效） - Node.js、Python 等工具链若安装在 Windows，不能被 WSL 中的 VSCode 调用；必须在 WSL 内通过
apt install nodejs或pyenv安装对应版本 - Git 配置、SSH 密钥、环境变量都以 WSL 用户为准（
~/.gitconfig,~/.ssh/id_rsa），Windows 的配置不会自动同步 - 若必须跨系统编辑同一项目，建议用 WSL 内部路径开发，用
code .命令从 WSL 终端启动 VSCode（会自动触发 Remote 连接）
调试、终端与扩展行为差异
进入 WSL 模式后，VSCode 表面不变，但底层执行环境已完全切换 —— 很多扩展和功能的行为会静默变化：
- 集成终端默认是 WSL 的 bash/zsh，不是 Windows 的 PowerShell；
Ctrl+`打开的就是该发行版 shell - 调试器（如 Node.js、Python）调用的是 WSL 中的二进制，断点位置、路径映射需匹配 WSL 路径（例如：launch.json 中
"program": "./index.js"是相对于 WSL 工作目录） - 某些扩展（如 Live Server、Prettier）需在 WSL 环境中重新安装，Windows 版本不会自动启用；检查扩展面板右下角是否显示
WSL标签 - 字体渲染、中文输入法、GPU 加速等 UI 层仍由 Windows 主程序控制，但文件操作、进程执行、网络请求全部经由 WSL 内核
最常被忽略的一点：WSL 关机后 VSCode 不会自动重连，且 ~/.vscode-server 可能因异常退出损坏。遇到“无法连接到 WSL”时，优先执行 wsl --shutdown 再重启 VSCode，比反复重装插件更有效。
