VS Code远程开发插件套装：WSL与容器开发配置全攻略
Remote-WSL扩展需手动启用，无法通过Remote Development套件自动激活
安装Remote Development扩展包后，许多开发者误以为Remote-WSL会自动准备就绪。实际上，VS Code需要您主动触发其加载——无论是首次点击“Remote-WSL: New Window”选项，还是在WSL终端中执行code .命令。如果操作后无响应，很可能是因为该扩展尚未被激活。
如何验证？打开命令面板（Ctrl+Shift+P），输入Remote-WSL: Show Log进行尝试。若系统提示“command not found”，则证实Remote-WSL仍处于未激活状态。
- 手动启用步骤：进入
Extensions面板 → 搜索Remote - WSL→ 关键操作是点击Enable按钮（请注意，此处是“启用”而非“安装”）。 - 安装位置检查：确认您使用的VS Code安装在Windows系统本身，而非WSL文件系统内（例如
/home/xxx/.vscode路径下的安装是无效的）。 - WSL版本确认：若仍在使用旧版WSL1，必须升级至WSL2。升级命令非常简单：
wsl --set-version Ubuntu-22.04 2。
Remote-WSL扩展必须手动启用，不能依赖Remote Development套件自动激活；首次使用需执行“Remote-WSL: New Window”或在WSL中运行code .命令触发加载，否则相关功能将不可用。
devcontainer.json配置中image与build字段不可同时使用
配置devcontainer.json文件时，一个常见错误是同时设置了"image": "mcr.microsoft.com/vscode/devcontainers/python:0-3.9"和"build": { "dockerfile": "Dockerfile" }。这将导致VS Code直接报错Cannot specify both 'image' and 'build'——请注意，这是严格的校验错误，而非可忽略的警告。
这两个字段的功能截然不同：image表示直接拉取预构建的容器镜像，启动速度快但定制性有限；而build则从本地Dockerfile开始构建镜像，可控性强但耗时较长。二者只需选择其一即可。
- 追求快速启动：对于新项目或标准开发环境，直接使用
image字段。微软维护的mcr.microsoft.com/vscode/devcontainers/xxx系列镜像已集成了常用的开发工具链。 - 需要深度定制：若项目依赖特定版本或有私有基础镜像需求，则应删除
image字段，仅保留build配置，并务必确保Dockerfile首行是有效的FROM指令。 - 注意路径问题：当
Dockerfile不在工作区根目录时，必须使用"context"字段指定相对路径，否则构建过程必然失败。
WSL2环境下Docker Desktop与原生Docker引擎冲突导致远程容器连接失败
在WSL2环境中，若同时安装了Docker Desktop（并启用了WSL2集成）和手动安装的docker-ce，极易引发命令冲突。具体表现为VS Code启动远程容器时卡在Starting container阶段，日志中反复出现Cannot connect to the Docker daemon错误。
问题的根源在于Docker守护进程的归属冲突。Docker Desktop默认会将其Socket挂载到WSL2的/var/run/docker.sock，而手动安装的docker-ce服务可能未启动，或监听于其他地址。
- 推荐解决方案：彻底卸载WSL2内部手动安装的
docker-ce，完全使用Docker Desktop进行管理。Docker Desktop与WSL2的集成已相当成熟稳定。 - 验证当前环境：在WSL终端运行
docker info | grep "Server Version"。若输出中包含docker-desktop字样，说明当前连接的是Docker Desktop引擎。 - 坚持使用原生引擎：若确有需求必须使用WSL2内部的原生Docker引擎，则需在Docker Desktop设置中（Settings → General）取消勾选“Use the WSL2 based engine”，然后在WSL内部手动启动Docker服务：
sudo service docker start。
WSL中执行code .未打开远程窗口，反而启动本地VS Code
在WSL终端中输入code .命令，期望打开连接到WSL环境的远程窗口，结果却启动了Windows本地的空白VS Code窗口——这个问题令人困扰。其根本原因在于，您调用的code命令未能正确绑定到WSL版本的VS Code。
通常，这源于两种可能：要么是初始安装VS Code时未勾选“Add to PATH”选项；要么是系统PATH环境变量中，Windows版的code命令路径优先级更高。
- 快速修复命令：可尝试在WSL的bash配置文件中添加路径。执行：
echo 'export PATH="/mnt/c/Users/$USER/AppData/Local/Programs/Microsoft VS Code/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc。 - 更可靠的方案：直接在WSL内部运行以下命令，强制注册WSL版本的
code命令：code --install-extension ms-vscode-remote.remote-wsl。 - 最终验证：执行
which code命令查看。理想输出应为/usr/local/bin/code（这是由Remote-WSL扩展创建的软链接），而非类似/mnt/c/...的Windows路径。
总结而言，WSL和容器开发流程中真正阻碍进展的，往往并非复杂的配置项，而是本地VS Code、WSL子系统与Docker引擎三者间的“通信链路”出现断点。尤其需要关注三个关键环节：code命令的真实来源、docker守护进程的实际控制者，以及Remote-WSL扩展是否已在WSL上下文中成功加载。这三个环节中任一出现错位，都可能导致整个开发流程陷入静默失败状态，排查起来反而更加耗时费力。
