remote development 扩展包含 remote-ssh、remote-containers、remote-wsl 三个独立组件，各自场景生效、配置隔离；ssh 依赖本地 ssh 可通及远程 curl/wget+tar；containers 要求 .devcontainer 在项目根目录且路径为 linux 风格；wsl 仅支持运行中 wsl2 发行版且开发须在原生文件系统进行。
Remote Development 扩展包不是单个插件，而是三个独立但协同工作的组件：Remote - SSH、Remote - Containers、Remote - WSL。装一个就全有，但每个组件只在对应场景下生效，不共享配置、不自动联动。
Remote - SSH 连不上？先确认这三件事
它只管通过 SSH 协议连 Linux/macOS 服务器，不处理密钥、不校验远程 shell 类型、也不帮你开防火墙。
- 本地
ssh user@host必须能通——VSCode 不会替你解决基础 SSH 连接失败（比如端口被拦、sshd没启、用户被禁） - 首次连接时，VSCode 会在远程自动生成并运行
vscode-server，但它依赖远程有curl或wget+ 解压工具（tar），缺一不可；某些精简版 Alpine 镜像或容器里会卡在这步 -
~/.ssh/config里如果用了ProxyJump或Include，VSCode 的 SSH 主机选择器不一定识别——建议用完整连接串（如ssh -o ProxyJump=jumpuser@jumphost user@target）手动添加
Remote - Containers 启动失败？检查 .devcontainer 路径和权限
它只认项目根目录下的 .devcontainer/devcontainer.json 或 .devcontainer/Dockerfile，且整个 .devcontainer 文件夹必须可读，不能是符号链接指向外部路径。
- Windows 上用 WSL2 作为容器运行时，
devcontainer.json中的"workspaceFolder"若写成 Windows 路径（如C:\project），会导致挂载失败——统一用 Linux 风格路径（如/workspace） - 如果 Docker daemon 运行在远程机器上（非本地），Remote - Containers 默认不支持——它只对接本地 Docker Socket（
/var/run/docker.sock） - 镜像拉取超时或被墙？别改
docker pull参数，直接在devcontainer.json加"runArgs": ["--dns", "8.8.8.8"]或配好 Docker daemon 的 registry mirrors
Remote - WSL 打不开项目？注意发行版状态和文件系统边界
它只激活已安装且正在运行的 WSL2 发行版（如 Ubuntu-22.04），不兼容 WSL1，也不支持从 Windows 文件系统（C:）直接打开子目录后“强制切换到 WSL”。
- 必须用 VSCode 在 WSL 环境中打开路径，例如在 Ubuntu 终端里执行
code /home/user/project；若从 Windows 启动 VSCode 再选 WSL 目录，会提示 “The folder you opened is on the Windows file system” 并退回到本地模式 - WSL 发行版未设置默认用户（比如重装后只剩 root），
code命令可能因权限失败——运行wsl -u <username></username>切换后再试，或重置默认用户：ubuntu2204 config --default-user <username></username> -
/mnt/c/下的文件可读，但编辑性能差、inotify 不可靠、Git 权限易乱——开发务必放在 WSL 原生文件系统（如/home/xxx）
三个组件共用同一个扩展包入口，但各自部署逻辑、依赖环境、错误日志位置都不同。出问题时别笼统搜 “Remote Development failed”，得盯住具体组件名 + 错误关键词（比如 vscode-server download failed 属于 SSH，Failed to connect to docker daemon 属于 Containers）。
