vs code docker插件本身不管理容器，仅调用本地docker cli；插件可用前提为docker命令在终端可执行、守护进程运行正常、用户具备相应权限。
VS Code 安装 Docker 插件本身没有技术门槛，但插件装完不等于能用——真正卡住人的，是插件和本地 Docker 环境之间的连接是否就绪。只要 docker 命令在终端能正常执行（比如运行 docker version 有输出），插件就能识别并工作；否则插件图标会灰掉、容器列表为空，这是最常见也最容易被忽略的前提。
如何确认 Docker CLI 已就绪
VS Code 的 Docker 插件不自己启动 Docker，它完全依赖系统 PATH 中的 docker 可执行文件。很多用户装完 Docker Desktop 后没重启 VS Code，或在 macOS/Linux 上用了非标准安装路径（比如通过 Snap 或手动解压），就会导致 VS Code 找不到命令。
- 打开 VS Code 内置终端（
Ctrl+`或Cmd+`），输入which docker，确认有返回路径（如/usr/bin/docker或/opt/homebrew/bin/docker） - 在同一终端中运行
docker version --format '{{.Server.Version}}'，应输出类似26.1.4的版本号 - 如果报错
command not found或Cannot connect to the Docker daemon，说明问题不在插件，而在 Docker 运行时本身
Docker 插件安装后看不到容器列表
插件图标（左栏 Docker 图标）点击后显示 “No containers” 或 “Loading…” 卡住，大概率是权限或守护进程未响应。Windows/macOS 用户常因 Docker Desktop 没启动或托盘图标显示“Docker is starting…”而误以为已就绪。
- 检查系统托盘（Windows/macOS）或状态栏（Linux），确认 Docker Desktop 显示 “Docker Desktop is running”
- Linux 用户需确保当前用户在
docker用户组：运行groups查看是否含docker，若无则执行sudo usermod -aG docker $USER并**完全退出并重登系统**（仅重启 VS Code 不生效） - 插件设置里不要手动改
docker.path，除非你明确知道docker二进制不在默认 PATH —— 改错反而会导致插件彻底失联
Remote - Containers 插件要不要一起装？
单纯管理镜像/容器，只装 Docker 插件就够了；但如果你打算在容器里直接写代码（比如用 .devcontainer.json 开发），就必须额外装 Remote - Containers。这两个插件职责完全不同，不能互相替代。
- Docker 插件：查日志、删镜像、启停容器、看卷挂载 —— 是运维视角
- Remote - Containers 插件：把整个 VS Code 前端“投射”进容器，共享文件系统和环境变量 —— 是开发视角
- 两者共存无冲突，但 Remote - Containers 依赖 Docker 插件提供的底层能力，所以建议先装 Docker 插件，验证可用后再装 Remote - Containers
真正容易被忽略的点是：插件装完只是“工具到位”，而 docker CLI 的可用性、用户权限、Docker 守护进程状态这三项，缺一不可。很多人反复重装插件，其实该检查的是终端里 docker info 能不能跑通。
