Remote-WSL扩展需手动启用，不能依赖Remote Development套件自动激活；首次使用须执行“Remote-WSL: New Window”或WSL中code .触发加载，否则命令不可用。
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（不是“Install”） - 确保VS Code是Windows本体安装的，不是装在WSL文件系统里（
/home/xxx/.vscode下装的无效） - 如果用的是旧版WSL1，必须升级到WSL2：
wsl --set-version Ubuntu-22.04 2
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又手动装过docker-ce，会导致docker命令指向不同后台，VS Code远程容器启动时卡在Starting container，日志里反复出现Cannot connect to the Docker daemon。
根本原因是Docker Desktop默认把WSL2的Docker Socket挂载到/var/run/docker.sock，而手动安装的docker-ce服务可能没启动，或监听地址不对。
- 首选方案：彻底卸载WSL2里的
docker-ce，只用Docker Desktop（它已深度集成WSL2） - 验证方式：在WSL终端运行
docker info | grep "Server Version"，输出应含docker-desktop字样 - 如果必须用原生引擎，停掉Docker Desktop的WSL2集成（Settings → General → “Use the WSL2 based engine”取消勾选），再在WSL里
sudo service docker start
code .在WSL中不打开远程窗口，而是启动本地VS Code
在WSL终端执行code .，结果弹出的是Windows本机的空白VS Code窗口，而不是连接到WSL的开发环境——这说明code命令没绑定到WSL版本。
原因通常是安装VS Code时没勾选“Add to PATH”，或者PATH里Windows的code优先级更高。
- 修复命令：
echo 'export PATH="/mnt/c/Users/$USER/AppData/Local/Programs/Microsoft VS Code/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc - 更可靠的方式：在WSL里运行
code --install-extension ms-vscode-remote.remote-wsl，强制注册WSL版code命令 - 验证：执行
which code，输出应为/usr/local/bin/code（由WSL扩展创建的软链接），不是/mnt/c/...
WSL和容器开发真正卡住的地方，往往不是配置本身，而是本地VS Code、WSL子系统、Docker三者之间的命令路由和权限链断了一环。尤其要注意code命令的来源、docker守护进程的实际归属、以及Remote-WSL扩展是否真正在WSL上下文中被加载——这三个点任何一个错位，整个流程就会静默失败。
