Windows和WSL中docker ps结果不同，是因为默认连接不同daemon：Windows CLI连Docker Desktop的docker-desktop发行版，而WSL终端若未启用集成则可能连本地无效daemon；需在Docker Desktop设置中开启WSL集成并设默认发行版，使WSL通过代理统一接入同一daemon。
Windows 上的 docker 命令和 WSL 里执行的 docker 命令，**默认不是同一个引擎**——它们可能连着不同的 daemon，所以看到的容器列表不一致是正常现象，不是数据丢了，也不是同步故障。
为什么 Windows 和 WSL 里的 docker ps 结果不同
这是典型的“双 daemon”错觉。Docker Desktop 在 Windows 上实际只启动一个 dockerd（运行在 WSL2 内部专用发行版 docker-desktop 中），但 Windows 主机上的 CLI 默认通过 \.pipedocker_engine 连接；而你在 WSL 终端里敲 docker ps，如果没额外配置，它会尝试走 Unix socket /var/run/docker.sock——这个路径在普通 WSL 发行版（比如 Ubuntu）里根本不存在，除非你手动把 Docker Desktop 的 socket 映射进去，或者启用了 WSL 集成。
更常见的情况是：你用 wsl --install 装了 Ubuntu，又单独在 WSL 里 apt install docker.io，这就真搞出了两个独立的 daemon：一个是 Docker Desktop 管的，一个是 WSL 自己跑的 dockerd（通常没配好、没启动、甚至没权限）。这时候两边 ps 当然不一样。
如何确认当前 docker 命令连的是哪个 daemon
不用猜，直接查连接目标：
- 在 Windows PowerShell 或 CMD 中运行：
docker context ls，看DEFAULT行对应的DESCRIPTION是不是desktop-linux；如果不是，说明 CLI 没连上 Docker Desktop - 在 WSL 终端中运行：
echo $DOCKER_HOST—— 如果输出为空，说明它走默认 socket；如果输出类似unix:///var/run/docker.sock，那它大概率连的是本地 WSL 的 daemon（大概率压根没跑起来） - 统一验证方式（推荐）：
docker info | grep "Name|Server Version|Platform"，重点看Name字段：docker-desktop表示连对了；ubuntu或其他发行版名，说明你正在用 WSL 自带的、非 Docker Desktop 托管的 daemon
怎么让 WSL 终端也连上 Docker Desktop 的 daemon
必须启用 Docker Desktop 的 WSL 集成，而不是靠 WSL 自己装 Docker：
- 确保 Docker Desktop 设置里已开启：
Settings → General → Use the WSL 2 based engine - 进入
Settings → Resources → WSL Integration，勾选Enable integration with my default WSL distro，并确保你的发行版（如Ubuntu）右侧开关是打开的 - 关闭所有 WSL 终端，重新打开一个新的，再运行
docker ps—— 此时应该和 Windows 终端结果一致 - 如果仍不一致，检查 WSL 发行版是否为默认：
wsl -l -s，如果不是，用wsl --set-default <name></name>设定；或在集成页手动开启对应发行版
容易被忽略的底层细节
WSL 集成不是“共享 socket 文件”，而是 Docker Desktop 后台自动在每个启用的发行版里注入一个轻量代理（docker-proxy），把 /var/run/docker.sock 请求转发到内部 docker-desktop 发行版的真正 daemon。这意味着：
- 你不能在 WSL 里
sudo service docker start，那会冲突；删掉 WSL 自装的docker.io包更干净 -
docker build的上下文路径如果是 Windows 文件（如/mnt/c/Users/xxx），性能会明显变慢——WSL2 对跨文件系统访问本就慢，这不是连接问题，是路径选错了 - 如果某天
docker ps在 WSL 里突然空了，先别重装，运行wsl --shutdown再重启终端，常能恢复集成代理
