VSCode Docker插件仅是调用本地docker CLI的轻量前端，非图形替代品；容器不显示需检查插件启用、daemon运行及Linux用户是否加入docker组；进入容器优先用/bin/sh；构建失败多因上下文路径错误或环境变量缺失，应终端启动VSCode。
VSCode 的 Docker 插件不是 Docker 的图形替代品，它不接管 daemon、不绕过 CLI、也不自动修复权限——它只是调用 docker 命令的轻量前端。所有“点不动”“看不到”“连不上”的问题，90% 都出在本地 CLI 环境没对齐，而不是插件本身坏了。
插件里看不到运行中的容器？先确认三件事
这不是界面刷新慢，而是插件根本没拿到 docker ps 的结果。
- 右键侧边栏 Docker 图标 → 确认插件未被禁用；按
Ctrl+Shift+P输入Docker: Toggle View能唤出面板才算启用成功 - 终端执行
docker info必须有输出（尤其含Server Version），报Cannot connect to the Docker daemon就别折腾插件了 - Linux 用户必须确保
groups输出包含docker；加组后要完全退出桌面会话再重登，仅重启 VSCode 无效
右键 “Exec in Container” 失败？别硬试 /bin/bash
很多镜像（比如 alpine、scratch 衍生镜像）压根没装 bash，插件默认列出的选项只是猜测，不是保证。
- 优先手动输入
/bin/sh—— 它比/bin/bash兼容性高得多 - 不确定容器里有什么 shell？先终端执行：
docker exec -it <container-id> ls /bin/ - 想让右键菜单默认走
/bin/sh：在 VSCodesettings.json加一行"docker.explorer.execCommand": "/bin/sh"
docker build 在插件里失败？上下文路径和环境变量是主因
插件右键 Dockerfile → Build Image，本质就是跑 docker build -f Dockerfile .，但它用的是当前文件所在目录作为上下文（.），不是项目根目录。
- 如果 Dockerfile 在
./src/Dockerfile，而COPY package.json .想复制根目录下的文件，构建必报错：找不到package.json - Linux 下从桌面图标启动 VSCode，
$PATH和DOCKER_HOST往往丢失；解决办法只有一条：code .从已验证能跑docker ps的终端中启动 - 构建日志藏在 Output 面板 → 切换到
Docker标签，比弹窗提示详细得多
删镜像提示 “unable to delete image”？不是插件卡，是 Docker 引擎在拒绝
插件调用的是 docker image rm，行为和命令行一模一样。报错说明镜像正被引用，强行删可能破坏层依赖。
- 先看插件里该镜像右侧是否标着
used by container；展开 Containers 节点，找有没有 stopped 但还挂着它的容器 - 终端查引用：
docker ps -a --filter ancestor=<IMAGE_ID> -q，有输出就先docker rm对应容器 - 想清悬空镜像（dangling）：
docker image prune，比盲目rm -f安全
最常被忽略的点：插件不感知 docker context 切换。你在终端执行 docker context use my-remote 后直接开 VSCode，插件仍连的是 default；必须用命令面板 Docker: Switch Context 手动切，且状态栏右下角会显示当前上下文——这个小字提示，很多人从来不会瞄一眼。
