vs code docker插件仅是调用本地docker cli的图形界面，所有问题根源在于cli连通性或权限：docker desktop未运行、linux用户未加入docker组、vs code未从终端启动导致环境变量丢失。
VS Code 的 Docker 插件本身不管理容器，它只是调用本地 docker CLI 的图形界面——所有“看不到容器”“点不动”“构建失败”的问题，根源几乎都在 CLI 连通性或权限上，而不是插件设置。
为什么 Docker 侧边栏里什么都没有？
这不是插件坏了，而是它根本没连上 dockerd。常见原因有三个：
-
docker info在终端执行报错？说明 Docker Desktop（或dockerd）根本没运行，先启动它 - Linux 用户：检查
groups输出是否含docker，不含就加进组：sudo usermod -aG docker $USER，然后重新登录 - macOS / Linux 下从桌面图标启动 VS Code？它会丢失
$PATH和DOCKER_HOST——必须从终端执行code .启动
右键容器 → Exec in Container 没反应或报 OCI runtime exec failed？
插件默认尝试 /bin/bash，但很多镜像（比如 alpine、distroless）压根没装 bash，只有 /bin/sh。
- 手动输入
/bin/sh（不是bash）再试一次 - 不确定容器里有什么 shell？先在终端跑：
docker exec -it <container-id> ls /bin/</container-id> - 想让右键菜单默认走
/bin/sh？在 VS Codesettings.json里加一行："docker.explorer.execCommand": "/bin/sh"
点击 Build Image 却提示 “Cannot connect to the Docker daemon”？
这和你在终端里直接敲 docker build 报的错一模一样——插件只是把命令转给 CLI 执行，它自己不处理连接逻辑。
- 别翻插件设置，去终端验证：
docker build -t test .能跑通吗？不能，就是环境问题 - Windows 用户基本不用操心；macOS 用户重点查
~/.zshrc或~/.bash_profile是否导出DOCKER_HOST - 构建日志其实在 Output 面板 → 切换到
Docker标签页，比弹窗提示详细得多
Remote - Containers 扩展和 Docker 插件是两回事
很多人混淆这两者：Docker 插件（鲸鱼图标）只管“看容器”，而 Remote - Containers（小电脑+容器图标）才是让你“在容器里写代码”的核心工具。
- 要编辑容器内代码、调试、装扩展？必须用
Remote-Containers: Reopen in Container，不是右键容器 Attach - Attach Visual Studio Code 是给已经按 devcontainer 规范启动的容器用的，普通
docker run启的容器不支持热附加 -
.devcontainer/devcontainer.json里的forwardPorts和extensions只对 Remote - Containers 生效，Docker 插件完全无视
真正卡住人的从来不是功能怎么点，而是 docker 命令在终端能跑，但在 VS Code 里就失效——这种隐性环境割裂，在 Linux/macOS 上尤其顽固，得靠终端命令一层层验，而不是依赖插件 UI 提示。
