VSCode Docker插件需先安装Docker Desktop/Engine并确保docker CLI在PATH中且daemon运行；Linux用户须将当前用户加入docker组；插件仅显示运行中容器，构建镜像时注意上下文路径，远程连接需手动配置DOCKER_HOST环境变量。
VSCode Docker插件装不上？先确认你有没有装对东西
VSCode 本身不自带 Docker 支持，必须手动安装官方 Docker 插件（ID：ms-azuretools.vscode-docker），且前提是本地已安装并运行了 Docker Desktop（macOS/Windows）或 Docker Engine（Linux）。插件装完没反应，90% 是因为 Docker CLI 不在系统 PATH 里，或者 daemon 没启动。
- Windows/macOS：打开终端执行
docker version，能输出客户端和服务端版本才算就绪；如果报command not found或Cannot connect to the Docker daemon，插件必然失效 - Linux 用户注意：
docker命令默认需要sudo，但 VSCode 插件不支持自动提权，得把当前用户加进docker组：sudo usermod -aG docker $USER，然后完全退出并重登会话 - 插件安装后，左下角状态栏会出现鲸鱼图标，点开才能看到容器、镜像、卷等资源树——不是装完就自动弹窗
点开容器却看不到日志？检查容器是否真的在运行
VSCode Docker 插件的「Containers」节点只显示正在运行的容器（docker ps 的结果），已退出的容器不会出现。想看历史日志或调试崩溃容器，得先右键容器名选「View Logs」，但前提是容器曾经输出过日志——空启动后立刻退出的容器，日志为空，插件里也查不到内容。
- 启动容器时别漏掉
-d（后台模式）：用docker run -d nginx才能在插件里看到它；docker run nginx运行完立即退出，插件里根本不会列出来 - 插件里右键「Attach Shell」只对正在运行的容器有效，如果容器进程主命令结束（比如用
sleep 10启动），shell 会瞬间断开，不是插件卡了 - 日志实时刷新有延迟，新日志可能要等 2–3 秒才出现在插件面板，别急着关窗口
从 Dockerfile 构建镜像失败？路径和上下文是最大雷区
插件里右键 Dockerfile → 「Build Image」，本质是执行 docker build，但它默认把当前文件所在目录设为构建上下文（build context）。如果你的 Dockerfile 在子目录（如 ./src/Dockerfile），而 COPY 指令引用的是项目根目录下的文件（如 COPY package.json .），构建必失败——因为插件传给 docker build 的上下文是 ./src，根本找不到 package.json。
- 确保
Dockerfile和它要COPY的所有文件都在同一个目录，或其子目录内；否则手动改docker build命令，用-f指定 Dockerfile 路径，用.指定正确上下文目录 - 插件构建时不支持自定义
--build-arg，如果 Dockerfile 依赖构建参数，得切到终端手动跑docker build --build-arg NODE_ENV=production -t myapp . - 构建过程中的错误信息直接输出在 VSCode 的「Docker」输出面板里，但不会高亮语法错误；
FROM写成FORM这种低级错，得自己盯输出里的unable to resolve提示
远程 Docker 主机连不上？别指望插件自动读 SSH 配置
插件默认只连本地 Docker daemon（unix:///var/run/docker.sock 或 tcp://127.0.0.1:2375）。想连远程服务器，必须手动配置环境变量 DOCKER_HOST，插件不会读你的 ~/.ssh/config 或自动走 SSH 隧道。
- Linux/macOS：在 VSCode 启动前设置环境变量，比如
export DOCKER_HOST=ssh://user@host，再用终端打开 VSCode（code .）；直接双击图标启动的 VSCode 不继承 shell 环境变量 - Windows：PowerShell 中用
$env:DOCKER_HOST="ssh://user@host"，同样要从该 PowerShell 启动 VSCode - SSH 连接需提前配置好免密登录，且远程主机上 Docker daemon 必须允许远程访问（默认不开启，要改
/lib/systemd/system/docker.service里的ExecStart加-H tcp://0.0.0.0:2375并重启服务——这步风险高，不建议非必要开启
插件对 Docker 的操作都建立在 CLI 可用的基础上，任何一步脱离了 docker 命令的实际能力，界面再好看也没用。最常被忽略的是：它不解决权限问题、不绕过网络限制、也不帮你修 Dockerfile 逻辑——它只是个 CLI 的图形壳子。
