vscode的docker扩展不运行容器，仅作为图形化操作层依赖本地已启动的docker引擎；90%问题源于docker命令不可达，需确保docker version成功、path正确、权限合规，并手动刷新容器列表。
VSCode 的 Docker 扩展本身不运行容器，也不替代 docker CLI；它只是个图形化操作层，所有功能都依赖你本地已启动、可通信的 Docker 引擎——装了扩展但 docker version 报错，等于没装。
docker 命令不可达是 90% 的“扩展不工作”原因
扩展启动时会尝试调用系统 PATH 中的 docker 命令。如果终端里能跑 docker ps，但 VSCode 里看不到容器，大概率是 VSCode 没读到你的 PATH：
- macOS 上用 Homebrew 安装 Docker Desktop 后，有时需完全退出 VSCode 再重开，否则 PATH 不更新
- Windows 用户若用 WSL2 作为后端，必须在 Docker Desktop 设置中勾选 “Use the WSL 2 based engine”，否则
docker命令在 VSCode 终端里可能指向 WSL 内部，而 daemon 在 Windows 主机上 - Linux 用户执行
sudo systemctl is-active docker返回inactive？先sudo systemctl start docker，再确认docker run --rm hello-world成功 - 别用
sudo code启动 VSCode——这会让它继承 root 环境，PATH 和 socket 权限全乱套
Containers 列表为空？不是插件坏了，是没刷新或容器根本没在跑
扩展不会自动轮询容器状态，也不会显示已退出的容器：
- 右键侧边栏 Docker 图标下的
Containers节点 →Refresh，或按F5键（不是 Ctrl+R） -
docker run nginx这种前台模式会立刻退出，插件里根本不会出现；要用docker run -d nginx启动后台容器 - 想看已停止的容器？右键
Containers→Toggle Show All Containers - 日志面板里空白？说明容器没输出过任何内容，或主进程已终止（比如
sleep 5启动的容器 5 秒后就没了）
从 Dockerfile 构建镜像失败，八成是上下文路径搞错了
VSCode 右键 Dockerfile → Build Image… 默认以当前文件所在目录为构建上下文（.），但 COPY 指令只能访问该目录及其子目录：
- 如果你的
Dockerfile在./src/Dockerfile，而它写的是COPY package.json .，那构建必然失败——因为package.json在项目根目录，不在./src - 验证方法：在终端手动执行
docker build -f ./src/Dockerfile -t myapp ./（注意最后的./是项目根目录） - 插件不支持自定义上下文路径，所以复杂结构建议直接用终端构建，把输出日志切到 VSCode 的
Output面板 →Docker通道看详情 - 多阶段构建没问题，但插件不会提示 stage 名称冲突；
AS builder和后续FROM builder必须拼写完全一致
Dev Container 调试才是扩展真正值钱的地方
比起点点点启停容器，和 devcontainer.json 配合才能实现「代码在容器里跑、调试器在 VSCode 里连、断点实时生效」：
- 按
Ctrl+Shift+P→ 输入Docker: Rebuild and Reopen in Container，它会自动构建镜像、启动容器、挂载源码、转发端口、加载 VSCode Server -
devcontainer.json里的forwardPorts必须显式列出你要调试的端口（如[3000, 9229]），否则浏览器打不开、调试器连不上 - 如果用了
"runArgs": ["--network=host"]，宿主机端口可能被占，得手动改forwardPorts或删掉这行 - Python/Go/Node.js 扩展在 Dev Container 模式下会自动安装到容器内，不是宿主机——这点常被忽略，导致插件看似启用实则无效
最易被忽略的一点：Docker 扩展 UI 上所有“删除”“停止”操作，都只是调用对应 CLI 命令，它不会帮你清理 dangling 镜像、未命名卷或网络。真要释放磁盘空间，还得回到终端敲 docker system prune -a——图形界面只是让你少记几个命令，不是帮你绕过 Docker 本身的逻辑。
