Docker volume是官方推荐的持久化方案，数据存于/var/lib/docker/volumes/下，与WSL2的.vhdx虚拟磁盘解耦；改.vhdx路径仅释放C盘空间，不影响卷的数据持久性。
不需要直接修改虚拟磁盘，Docker Desktop 的持久化数据靠 docker volume 管理，和虚拟磁盘（.vhdx）是解耦的。你改不改它，都不影响卷能否存住数据。
为什么改 .vhdx 路径 ≠ 解决数据持久化问题
很多人混淆了“容器删了数据还在”和“Docker 存储目录在哪个盘”这两件事：
-
docker volume create mydb创建的卷，数据实际落在/var/lib/docker/volumes/mydb/_data—— 这个路径在 WSL2 内部，由 Docker 引擎自动管理，与宿主机路径无关 - WSL2 的
ext4.vhdx文件只是承载整个 Linux 文件系统的容器，它变大是因为卷、镜像、容器层都写进了这个虚拟磁盘，但你并不需要手动操作它来实现持久化 - 真正决定“删容器不丢数据”的，是挂载时用了
-v mydb:/var/lib/postgresql/data这类命名卷，而不是路径是否在 D 盘
docker volume 和 bind mount 访问路径差异明显
在 Windows 上访问卷内容，必须分清你是从哪边看：
- 从 Windows 文件管理器：用
\wsl$docker-desktop-data ersion-pack-datacommunitydocker olumesmydb_data—— 这是 9P 协议暴露的路径，可读可写，但小文件频繁操作延迟高 - 从 WSL2 终端：
ls /var/lib/docker/volumes/mydb/_data会报错（Permission denied），因为该路径在 WSL2 内部被 Docker 进程锁定，普通用户不可见 - 从容器内：
cat /var/lib/postgresql/data/PG_VERSION可正常读取，说明卷挂载生效，且权限由容器 UID/GID 决定，不是 Windows 用户权限
Windows 下修改存储路径的真正目的和风险点
改 Disk image location 或迁移 docker-desktop-data，唯一目的是释放 C 盘空间，不是为了“让数据更持久”或“让卷更好访问”：
- 方法一（设置界面改
Disk image location）会触发完整数据迁移，耗时长，中途断电可能卡在半途，需预留 2 倍原磁盘空间用于临时拷贝 - 方法二（
wsl --export/--import）要求目标路径是 NTFS 格式，且不能是 OneDrive 同步文件夹、加密卷或符号链接目录，否则导入后 Docker 启动失败 - 方法三（
daemon.json的data-root）在 WSL2 后端下基本无效 —— 因为 Docker Desktop 强制将所有数据写入docker-desktop-data发行版，改了也 fallback 回默认路径
最常被忽略的一点：卷本身可以跨 WSL2 实例迁移，但 docker-desktop-data 一旦迁移完成，旧路径里的 .vhdx 文件必须手动删除，否则它还占着 C 盘空间，而你根本意识不到它的存在。
