Docker Desktop 升级至4.30.0+后镜像“消失”是真实删除，旧版ext4.vhdx文件被自动移除且不可恢复，数据未迁移至新路径C:\Users[用户名]\AppData\Local\Docker\wsl\main\ext4.vhdx。
更新 Docker Desktop 后镜像全没了，是数据被删了
不是“异常”，是真实删除——Docker Desktop 从 4.30.0 开始，升级会自动移除旧的 ext4.vhdx 文件，而它正是你所有镜像、容器、卷的存储载体。新版本改用 C:\Users\[用户名]\AppData\Local\Docker\wsl\main\ext4.vhdx，旧路径 C:\Users\[用户名]\AppData\Local\Docker\wsl\data\ext4.vhdx 被直接丢弃，且不可恢复。
常见误判：看到 docker images 返回空列表，以为只是“没加载”，实际是文件已不存在。Windows 资源管理器里也看不到 docker-desktop-data 这个 WSL 分发版，说明它已被卸载。
- 升级前没导出镜像？
docker save+tar备份已无效——因为docker命令此时连旧数据都访问不到 - 想回退？必须卸载当前版本，手动重装旧版（如
4.29.0），再从系统还原点或备份中恢复整个wsl\data目录 - 别指望
wsl --import恢复：新版 Docker Desktop 不认旧分发版格式，强行导入会导致启动失败或无限重启
如何确认是不是镜像丢失，而不是拉取失败
先排除网络或配置问题：运行 docker pull hello-world。如果成功拉取并运行，说明 daemon 正常，只是本地镜像库为空；如果报错 Error response from daemon: Get "https://registry-1.docker.io/v2/..."，才是网络或 registry 问题。
关键区分点：
-
docker images空，但docker pull成功 → 镜像确实丢了，不是网络问题 -
docker images有旧镜像，但docker run报No such image→ 镜像元数据损坏，需docker image prune -f清理后重拉 -
docker info显示Storage Driver: overlay2但Root Dir:指向/var/lib/docker→ 你正在用 Linux 原生 Docker，不是 Docker Desktop，和 WSL 数据丢失无关
升级后容器启动报 “image not found” 却能 docker pull
这通常不是镜像问题，而是容器启动时引用了旧镜像 ID 或 dangling 镜像名，而新环境里同名 tag 已指向不同内容。比如你原来用 myapp:latest 启动过容器，升级后重新 docker pull myapp:latest，但旧容器配置仍绑定在已删除的镜像上。
操作建议：
- 查清容器真正依赖的镜像：
docker inspect| grep -A 5 Image - 不要直接
docker start，改用docker run重建：显式指定刚拉下来的镜像 ID（sha256:abc...）或带 digest 的 tag（myapp@sha256:...） - 若用
docker-compose.yml，检查image:字段是否写死旧 tag；建议改用固定 digest，避免隐式覆盖 - 注意
docker ps -a中状态为Created的容器：它们尚未启动，但镜像已不存在，docker rm后再run更安全
WSL 分发版不显示、wsl -l -v 没有 docker-desktop-data
这是升级后的标准行为，不是故障。Docker Desktop 4.30+ 彻底废弃 docker-desktop-data 分发版，所有数据迁移到 docker-desktop（主分发版）下的 main 子目录。所以 wsl -l -v 只能看到 docker-desktop，且状态为 Running 就代表正常。
但如果 wsl -l -v 什么也不返回，或显示 Stopped，说明 WSL 底层异常：
- 执行
wsl --shutdown，再wsl -l -v看是否恢复 - 若仍无响应，用管理员权限运行
wsl --update，完成后重启机器（不是仅重启 WSL） - 检查 Windows 功能里是否勾选了“适用于 Linux 的 Windows 子系统”和“虚拟机平台”，缺一不可
- 不要手动
wsl --unregister docker-desktop-data：它已不存在，命令会报错且可能干扰新分发版初始化
最易被忽略的一点：Docker Desktop 升级不是“覆盖安装”，而是“重建 WSL 环境”。所有用户态数据（镜像、容器、构建缓存、自定义网络）都不继承。生产环境务必把镜像仓库地址、daemon.json 配置、compose 文件纳入版本控制，而不是依赖本地 docker images 列表。
