必须执行 wsl --shutdown 并重启发行版，因为 Docker Desktop 的 WSL 集成非热生效，需重新加载 /etc/wsl.conf 挂载配置及 9P 协议暴露的 docker.sock，否则 docker 命令无法连接守护进程。
开启 Docker Desktop 的 WSL Integration 后，wsl --shutdown 是必须操作，但「重启整个子系统」不是指重装或重置发行版，而是让 WSL2 实例重新加载集成配置——不执行这步，docker 命令在 Ubuntu/Debian 等发行版里大概率报 Cannot connect to the Docker daemon。
为什么改了 Settings 但 wsl 里 still no docker？
Docker Desktop 的 WSL 集成不是“热生效”。它依赖两个底层动作：① 在目标发行版（如 Ubuntu-22.04）的 /etc/wsl.conf 中注入 socket 挂载配置；② 把 docker-desktop 发行版里的 dockerd 监听地址通过 9P 协议暴露给其他发行版。这两件事只在 WSL 实例启动时读取一次。如果发行版已经运行，配置不会自动刷新。
常见错误现象包括：
-
docker version在 PowerShell 里正常，但在wsl -d Ubuntu里提示command not found或连接拒绝 - 手动运行
sudo service docker start失败，因为 WSL 集成模式下不走 systemd - WSL 设置里已勾选发行版，但
ls /var/run/docker.sock返回No such file or directory
怎么确认集成配置真生效了？
不要只看 Docker Desktop GUI 里打了勾，要验证三个关键点：
- 检查目标发行版是否被标记为集成启用：
wsl --list --verbose输出中对应发行版的STATE是Running，且该发行版名出现在 Docker Desktop 的Resources → WSL Integration列表中并已勾选 - 进入发行版后，确认
/var/run/docker.sock存在且可访问：ls -l /var/run/docker.sock应显示指向\.pipedocker_engine的符号链接（WSL2 自动创建） - 测试 CLI 连通性：
docker info --format '{{.OSType}}'应输出linux，而不是报错或卡住
如果任一环节失败，说明集成未真正就绪，不是界面勾选了就算数。
wsl --shutdown 后还要手动进发行版做啥？
wsl --shutdown 只是杀掉所有正在运行的 WSL2 实例，但它不负责重载配置或重建 socket 路径。你需要再手动触发一次发行版启动，让 WSL 加载更新后的挂载规则：
- 关闭所有 WSL 终端窗口（包括 VS Code 的 WSL 窗口、Windows Terminal 的 tab）
- 在 PowerShell（非管理员）执行：
wsl --shutdown - 再执行：
wsl -d Ubuntu-22.04（替换成你实际用的发行版名） - 进去后立刻运行：
docker ps -q | head -1，有输出即表示链路通了
注意：wsl --update 不影响集成状态，它只更新内核；wsl --set-default-version 2 也与此无关，那是控制新发行版默认版本的。
容易被忽略的权限和路径陷阱
即使 /var/run/docker.sock 存在，也可能因用户 UID 不匹配导致 Permission denied。Docker Desktop 默认把 socket 暴露给发行版里的 root 用户，而普通用户需要属于 docker 组才可直连：
- 检查当前用户是否在
docker组：groups，若无，运行sudo usermod -aG docker $USER - 该命令不会立即生效，需退出 WSL 再重新进入（
wsl --shutdown+wsl -d Ubuntu） - 别试图在 WSL 里手动
sudo dockerd—— Docker Desktop 管理的dockerd只运行在docker-desktop发行版中，其他发行版里启动会冲突
最常被跳过的一步，是改完设置后没关掉所有 WSL 终端就直接测试，结果看到的还是旧环境缓存。WSL2 不像 Linux 服务那样 reload 就行，它靠进程生命周期驱动配置加载。
