根本原因是docker守护进程未运行或用户无访问权限：linux需将用户加入docker组并完全注销重登，mac/windows需确认docker desktop已启动且图标稳定，wsl2需确保context为default并用remote-wsl模式打开。
Cannot connect to the Docker daemon 这个错误不是 VSCode 插件坏了，而是它根本没连上 Docker 守护进程——要么进程压根没跑，要么你没权限碰它。
docker ps 在终端失败，VSCode Docker 插件必然失效
VSCode Docker 插件底层调用的是 docker CLI 命令，它和你在终端里敲 docker ps 是同一套权限逻辑。如果终端里就报错，插件不可能绕过去。
先做最硬的验证：
- 打开终端，直接运行
docker ps - 如果返回
Cannot connect to the Docker daemon或permission denied，问题不在 VSCode，而在 Docker 环境本身 - 不要用
sudo docker ps测试——这掩盖了真实权限缺陷，插件不会自动加sudo
Mac / Windows 用户请确认 Docker Desktop 已启动且右上角鲸鱼图标稳定；Linux 用户检查 systemctl status docker 是否 active (running)。
Linux 下用户没进 docker 组，登出重进才是关键
很多用户执行了 sudo usermod -aG docker $USER 就以为完事了，结果 VSCode 依然报错——因为图形会话不读新组信息。
必须走完整流程：
- 执行
sudo usermod -aG docker $USER - 完全注销当前桌面会话（不是关 VSCode，不是重启终端，是点“注销”或重启系统）
- 重新登录后，在终端运行
groups，确认输出里有docker - 再用终端启动 VSCode：
code，而非点击桌面图标（图标启动继承旧会话权限）
newgrp docker 只临时生效于当前 shell，对 GUI 进程无效；只重启 VSCode 或只新开终端都不解决问题。
WSL2 + Docker Desktop 场景下 context 错位是隐形坑
在 WSL2 中用 Windows 的 Docker Desktop 时，VSCode 若以本地模式打开 WSL 文件夹，会默认找 WSL 里的 /var/run/docker.sock——但那里面没守护进程。
正确姿势：
- 确保 Docker Desktop 设置中启用了
Use the WSL 2 based engine，并勾选你的发行版（如Ubuntu-22.04） - VSCode 必须通过 Remote - WSL 扩展打开，窗口左下角显示
WSL: Ubuntu - 终端里运行
docker context ls，确认当前defaultcontext 指向本地 socket（不是desktop-linux或空） - 若 context 异常，运行
docker context use default
这个错不会报明显错误，但插件列表全空、右键无 Docker 菜单——本质是 CLI 连到了一个不存在的 endpoint。
Docker: Path 配置错位会导致静默失败
VSCode 默认从 $PATH 找 docker，但某些环境（如 macOS Homebrew M1 安装、自定义 prefix 编译）会让 which docker 返回非标准路径，比如 /opt/homebrew/bin/docker。
插件找不到可执行文件时，不会弹红字提示，只会卡在“Loading…”或列表为空。
修复方法：
- 终端运行
which docker，记下完整路径 - VSCode 里按
Cmd+Shift+P→ 输入Docker: Configure Path（或搜设置里的Docker: Path） - 填入上面拿到的路径，保存后执行
Developer: Reload Window
别漏掉 reload 步骤——配置改了但窗口不重载，插件仍用旧 PATH。
真正容易被忽略的是：Docker Desktop 启动后可能需要 10–20 秒才完成 socket 初始化，刚点开 VSCode 就刷新 Docker 视图，很可能抢在守护进程 ready 之前失败。等鲸鱼图标稳定后再操作，比反复重试更省时间。
