VSCode Docker插件仅是调用本地docker CLI的轻量前端，看不到容器、进不去shell或构建失败，90%源于CLI层问题：需确保docker daemon运行、用户权限正确（Linux加docker组并重登）、上下文为default、从终端启动VSCode以继承环境变量，并通过docker info等命令验证连通性。
VSCode 的 Docker 插件不是 Docker 替代品，它只是调用本地 docker CLI 的轻量前端——插件里看不到容器、进不去 shell、构建失败，90% 是 CLI 层出了问题，不是插件坏了。
为什么 Docker 插件里完全看不到容器？
这不是 UI 卡顿或没刷新，而是插件根本没拿到 docker ps 的输出结果。
- 先在 VSCode 内置终端（
Ctrl+`）里执行docker ps：如果报Cannot connect to the Docker daemon，插件必然为空 - Linux 用户检查
groups输出是否含docker；不含就运行sudo usermod -aG docker $USER，然后**完全退出系统重登**（只重启 VSCode 不生效） - macOS/Windows 用户确认 Docker Desktop 托盘图标已稳定显示（绿色），且已完成初始化（首次启动需等几秒）
- 插件默认只读取
defaultcontext，如果你用过docker context use my-remote，得手动在命令面板输入Docker: Switch Context切回来
右键 “Exec in Container” 提示 OCI runtime exec failed？
容器里压根没装你点的那个 shell——插件默认列出 /bin/bash 和 /bin/sh，但很多镜像（比如 alpine、distroless）连 bash 都没有。
- 优先试
/bin/sh：它比bash更轻量、存在率更高 - 不确定容器里有啥？终端执行
docker exec -it看真实路径ls /bin/ - 想让右键菜单默认走
/bin/sh：在 VSCodesettings.json里加一行"docker.explorer.execCommand": "/bin/sh" - 注意：只有正在运行的容器才能 exec；主进程退出（如
sleep 10跑完）后，shell 会立刻断开，不是插件问题
从 Dockerfile 构建镜像失败，错误却只显示 “Build failed”？
插件把构建日志藏在 Output 面板里，不点开根本看不到真实原因——多数是上下文路径或文件引用错位。
- 右键
Dockerfile→Build Image…时，插件默认以该文件所在目录为构建上下文（.） - 如果
Dockerfile在./src/Dockerfile，但里面写COPY package.json .，而package.json其实在项目根目录，构建必失败 - 解决方法：把
Dockerfile和所有COPY源文件放在同一目录下；或改用终端命令，显式指定上下文：docker build -f ./src/Dockerfile -t myapp ./ - 构建日志在哪看？打开 Output 面板（
Ctrl+Shift+U），左上角下拉选Docker标签
插件提示 “Cannot connect to the Docker daemon” 但终端里 docker ps 好好的？
VSCode 启动方式导致环境变量丢失——特别是 Linux 和 macOS，桌面图标或 Dock 启动的 VSCode 拿不到 shell 的 $PATH 和 DOCKER_HOST。
- 必须从终端启动：Linux/macOS 运行
code .，Windows（WSL2）运行code .（确保是在 WSL2 发行版终端里） - macOS 用户若用
zsh，检查~/.zshrc是否导出DOCKER_HOST（Docker Desktop 通常自动处理，但自定义配置可能覆盖） - Windows 用户若用 WSL2 backend，别在 WSL2 里装独立 Docker Engine——统一用 Windows 上的 Docker Desktop，并确认
docker context指向desktop-linux
真正容易被忽略的是：插件所有操作都依赖一次成功的 docker info 调用，但它不会告诉你哪一步挂了。与其反复点刷新按钮，不如先把终端里的 docker info、docker ps、docker version 这三条命令跑通——剩下的，只是界面操作而已。
