根本原因是WSL发行版中/var/run/docker.sock权限错误或用户未加入docker组；需确认docker-desktop-data运行、启用Docker Desktop的WSL集成、修复socket权限（srw-rw---- root:docker）、并将用户加入docker组后完全重启终端。
为什么Docker Desktop在WSL里报“permission denied”连接套接字
根本原因不是WSL没起来，也不是Docker Desktop没装好，而是WSL发行版（比如Ubuntu）里的docker.sock文件权限不对，或者当前用户没被正确加入docker组。WSL2本身不自带Docker守护进程——Docker Desktop会在docker-desktop-data这个专用发行版里运行dockerd，再通过Unix域套接字暴露给其他发行版（如你的Ubuntu）。如果你在Ubuntu里执行docker ps失败，十有八九是这条通信链断在了套接字访问环节。
检查wsl --list -v确认docker-desktop-data是否就绪
先确认底层依赖是否真正跑起来了：
- 以管理员身份打开PowerShell，运行
wsl --list -v，看输出里有没有docker-desktop和docker-desktop-data，且状态都是Running - 如果其中任一为
Stopped或压根没出现，说明Docker Desktop的WSL后端没初始化成功，此时docker.sock根本不存在，别急着改权限——先运行wsl --shutdown，再重启Docker Desktop - 如果两个发行版都存在但
docker-desktop-data启动缓慢（卡在Starting），可能是磁盘I/O阻塞或ext4.vhdx文件损坏，对应错误码0x80070570，需清理或重置
在WSL发行版里验证/var/run/docker.sock是否存在且可读
进入你日常使用的发行版（如Ubuntu），执行以下检查：
- 运行
ls -l /var/run/docker.sock：理想输出是srw-rw---- 1 root docker ... /var/run/docker.sock；如果提示No such file or directory，说明Docker Desktop没把套接字挂载进来，常见于WSL集成开关未启用 - 如果文件存在但属组不是
docker，或权限不是660，手动修复：sudo chown root:docker /var/run/docker.sock && sudo chmod 660 /var/run/docker.sock - 确认当前用户在
docker组：groups命令输出应含docker；若没有，执行sudo usermod -aG docker $USER，然后**必须完全关闭所有WSL终端窗口并重新打开**，否则组变更不生效
检查Docker Desktop设置里的WSL集成开关是否开启
这个开关常被忽略，但它直接控制套接字是否挂载到你的发行版：
- 打开Docker Desktop → Settings → Resources → WSL Integration
- 确保左侧“Enable integration with my default WSL distro”已勾选，并且右侧列表里你日常用的发行版（如Ubuntu-22.04）的开关是ON状态
- 如果之前关过，改完要点击Apply & Restart，否则更改不生效；改完后进WSL执行
ls /var/run/docker.sock应该能立刻看到文件 - 注意：某些旧版Docker Desktop（如wsl --set-default Ubuntu-22.04
最容易被跳过的点是：改完usermod不重启终端，或开了WSL Integration却没点Apply & Restart。这两个动作看似微小，但会直接导致docker命令永远卡在权限拒绝，而不是服务没启——问题不在守护进程，而在你和它的“握手方式”。
