vscode docker插件报“permission denied”错误的根本原因是当前用户未加入docker组且未重启图形会话。必须执行sudo usermod -ag docker $user后完全注销并重新登录，使组权限生效，再启动vscode（推荐终端执行code），否则插件无法访问/var/run/docker.sock。
VSCode Docker插件报 Got permission denied while trying to connect to the docker daemon socket
这个错误不是 VSCode 或插件本身的问题，而是当前用户没有权限访问 /var/run/docker.sock。VSCode 启动时继承了桌面会话的用户权限，如果该用户没被加入 docker 组，插件调用 docker CLI 时就会被拒绝。
- 必须确保终端里运行
docker ps也成功（否则插件肯定失败） - 不要只在终端里用
sudo docker ps测试——这掩盖了真实权限问题 - VSCode 若通过桌面快捷方式启动（比如 GNOME 或 KDE），不会自动加载新用户组，必须完全重启会话
为什么 sudo usermod -aG docker $USER 后 VSCode 还连不上
加组操作不会立即生效，尤其对已登录的图形会话：
-
newgrp docker只对当前 shell 生效，不影响 GUI 应用 - VSCode 桌面图标启动的进程不读取新 group，即使你新开一个终端再启动 VSCode 也不行
- 常见误操作：改完组后只重启 VSCode，没登出重进桌面环境
正确做法是：
- 运行
sudo usermod -aG docker $USER - 完全退出图形界面（选“注销”或关机重启）
- 重新登录后，在终端确认
groups输出包含docker - 再启动 VSCode（推荐从终端执行
code，避免桌面环境缓存旧权限）
WSL2 环境下 VSCode Docker 插件连不上怎么办
WSL2 中 Docker 守护进程默认不自动启动，且 VSCode Remote - WSL 插件与本地 Docker Desktop 的集成有特殊路径要求：
- 如果你用的是 Windows 上的 Docker Desktop + WSL2 后端：确保 Docker Desktop 设置中启用了
Use the WSL 2 based engine，并勾选对应发行版（如 Ubuntu-22.04） - 如果你在 WSL2 里自行安装了
docker-ce（非 Desktop）：需手动启动守护进程，sudo service docker start，并确认sudo systemctl enable docker已设置 - VSCode 必须以 WSL 模式打开（窗口左下角显示
WSL: Ubuntu），不能以 Windows 本地模式打开 WSL 文件夹 - 检查
docker context ls，确保当前 context 是default（指向本地 socket），不是远程或空 context
chmod 0666 /var/run/docker.sock 能临时解决但不推荐
这个操作会让所有用户都能读写 Docker socket，等价于把主机 root 权限开放给任意本地账户：
- 一旦启用，任何能登录你系统的普通用户都可逃逸容器、挂载宿主机根目录、执行任意命令
- VSCode 插件、脚本、甚至网页里的 WebAssembly 都可能间接触发恶意容器操作
- 它绕过了 Linux 的 group 权限模型，后续升级或重装 Docker 可能被覆盖回安全默认值
真正该做的只有两件事：把用户加进 docker 组 + 重启会话。其他都是妥协方案，埋下运维和安全债。
复杂点在于：权限变更在 GUI 环境中不是“改完就生效”，而是依赖会话重建；而很多人卡在这一步，反复加组、反复重启 VSCode，却漏掉了登出桌面这关键一环。
