vscode docker插件仅是本地docker cli的图形化封装，所有功能依赖docker daemon运行、上下文路径正确及用户权限到位；看不到容器或镜像需检查上下文是否为default、linux用户是否加入docker组并重登、docker desktop是否启动，构建失败多因上下文路径错误或.dockerignore缺失。
VSCode Docker插件本身不提供独立的容器或镜像管理能力，它只是调用本地 docker CLI 的图形化封装；所有操作成败取决于你本地 Docker 环境是否就绪、上下文路径是否正确、权限是否到位——装上插件 ≠ 能用。
为什么 Docker 插件里看不到镜像或容器
根本不是插件坏了，而是它连不上 Docker daemon 或压根没识别到资源。
- 终端执行
docker ps和docker images能列出内容，但 VSCode 侧边栏为空 → 检查状态栏右下角是否显示上下文名（如default），若显示none或空白，说明插件初始化失败；按Ctrl+Shift+P输入Docker: Switch Context手动切回default - Linux 用户运行
docker ps需要sudo，但 VSCode 不支持自动提权 → 必须执行sudo usermod -aG docker $USER，然后完全退出当前桌面会话（仅重启 VSCode 无效） - Mac/Windows 上 Docker Desktop 没启动，或启动后托盘图标非绿色 → 插件必然报
Cannot connect to the Docker daemon，此时左下角鲸鱼图标会变灰
右键“Build Image”没反应或构建失败
插件只是把你的鼠标点击翻译成一条 docker build 命令，失败原因全在 CLI 层面。
- 右键菜单灰色或点击无响应 → 先确认当前工作区是以文件夹形式打开的（不是只打开了单个
Dockerfile），且该文件夹下存在名为Dockerfile的文件（不支持Dockerfile.prod等变体，除非手动指定） - 构建时报
COPY failed: forbidden path outside the build context→ 错误在docker build的上下文路径。插件默认以当前打开的文件夹为上下文（即docker build .），而COPY ../package.json .这类跨目录引用必然失败 - 想用子目录里的
Dockerfile？别依赖右键菜单，改用命令面板：Ctrl+Shift+P→Docker: Build Image→ 它会让你选Dockerfile路径和上下文路径，两个都填对才行
Dockerfile 编写时容易忽略的关键点
语法高亮和补全是假象，真正决定构建成败的是路径、基础镜像和指令顺序。
-
COPY和ADD的源路径永远相对于构建上下文目录，不是相对于Dockerfile所在位置。例如上下文是./，Dockerfile在./backend/Dockerfile，那COPY package.json .就要求package.json在项目根目录，而不是./backend/ -
WORKDIR /app后，所有后续RUN、COPY都基于此路径，但COPY的源仍受上下文限制 —— 这一点新手最容易混淆 - 没配
.dockerignore？构建时可能把node_modules、.git全塞进镜像，导致体积暴增、缓存失效；插件不会提醒你，.dockerignore是由 daemon 解析的，插件只静默生效
容器启动后插件里找不到或日志为空
插件的「Containers」节点只显示 docker ps 结果，也就是当前正在运行的容器。
-
docker run nginx运行完立即退出 → 插件里根本不会出现这个容器。要让它持续运行，必须加-d（后台模式）：docker run -d nginx - 容器启动了但日志面板空着 → 可能是应用没输出（比如
sleep 10）、或 stdout 被重定向了；插件读的是docker logs输出，空日志 = 容器没打任何 log - 右键「Attach Shell」失败或秒断 → 容器主进程已结束（如
sh -c "echo hi; sleep 1"），不是插件问题，是容器生命周期结束了
最常被跳过的环节是验证 docker info 是否能返回结果，以及确认 VSCode 是以和终端相同的用户身份启动的——这两点不满足，后面所有操作都是在调试一个根本没连上的连接。
