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获取的地址可能变化，HostName在~/.ssh/config中需手动更新（除非你写脚本固化 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 自动管理：
Windows TTS (WSL2)
下载
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
- 确保已运行
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@<windows-host-ip></windows-host-ip>，而不是ssh user@localhost（后者连的是 Windows 自身的 OpenSSH Server，不是 WSL）
本地开发请彻底放弃 SSH 连 WSL 的念头——它解决的是不存在的问题，却带来一堆真实存在的坑。
