VSCode如何使用SSH连接WSL_Windows子系统开发配置

Remote-WSL插件才是连接WSL的正确方式，它通过AF_UNIX socket直连、零配置、低延迟；而Remote-SSH方式会引发IP变动、sshd手动配置、服务冲突等问题，仅适用于跨机器访问WSL的特殊场景。

先说个核心判断：VSCode用SSH连WSL虽然技术上行得通，但纯粹是绕远路。Remote - WSL插件才是官方推荐的正道，零配置、低延迟；SSH方案反而会踩进IP变动、服务未启动、端口冲突这些坑里。

为什么不该用Remote-SSH连WSL

WSL本质上是个本地进程，不是远程服务器，强行走SSH等于多绕了一重没必要的抽象。

• 每次WSL重启后，ip addr拿到的地址都可能不一样，~/.ssh/config里的HostName得手动更新——除非你写脚本固化IP，但这又多了维护成本。
• 必须手动捣鼓WSL内的sshd：安装openssh-server、生成host keys、改/etc/ssh/sshd_config允许密码或密钥登录、再sudo service ssh start——随便哪一步卡住就连接不上。
• Remote-SSH会在WSL里部署自己的server组件，和Remote-WSL安装的~/.vscode-server冲突，可能导致扩展加载异常或者调试器挂起。
• 终端默认还是Windows shell，得手动切到WSL；而Remote-WSL下终端天然就是bash或zsh，省心多了。

Remote-WSL才是开箱即用的正解

它不依赖网络栈，直接通过WSL2的AF_UNIX socket通信，性能接近本地，所有管理都交给VSCode自动处理。

• 先跑一下wsl -l -v，确认对应发行版的VERSION列是2，状态是Running。
• 在VSCode扩展市场装Remote - WSL（发布者Microsoft），警告一句：千万别装Remote-SSH来连WSL。
• 打开命令面板（Ctrl+Shift+P），输入WSL: New Window——这会启动一个新窗口，底部状态栏会显示WSL: Ubuntu（或者你的发行版名）。
• 在这个窗口里，用File→Open Folder选路径，必须是Linux路径，比如/home/username/project；绝不能选/mnt/c/Users/xxx/project或C:\...。

常见误操作导致“看起来连上了，实则还在Windows环境”

最典型的假连接：在Windows文件资源管理器里右键“Open with Code”，或者从Windows终端执行code /mnt/c/project——这时候VSCode还在Windows模式下运行，所有终端、任务、调试器都调用Windows工具链，npm、python3、gcc全都失灵。

• 正确做法只有一条：先确认当前VSCode窗口底部状态栏明确显示WSL: xxx，再打开项目。
• 验证是否真在WSL环境：打开集成终端，执行uname -a，输出应该包含Microsoft和WSL2字样；执行which python3应该返回/usr/bin/python3，而不是C:\Users\...。
• 如果误开了Windows路径，别挣扎，关掉当前窗口，重新执行WSL: New Window。

真要用SSH连WSL的唯一合理场景

只有当你需要从另一台机器（比如Mac或Linux笔记本）通过网络访问本机WSL时才有必要。这时候WSL才算得上“远程主机”。

• 在WSL里运行sudo service ssh start，再确认sudo ss -tlnp | grep :22有监听。
• Windows防火墙要放行TCP 22端口，WSL的/etc/ssh/sshd_config里ListenAddress至少包含0.0.0.0或具体IP。
• 从外部机器执行ssh user@，而不是ssh user@localhost——后者连的是Windows自身的OpenSSH Server，不是WSL。

本地开发就该彻底放弃SSH连WSL的念头——它解决的压根不是问题，却会带来一堆真实存在的坑。