docker desktop卷挂载失败根因是系统层拦截：windows/macos需在settings→resources→file sharing中显式授权路径，且路径不能含中文、空格或符号；绑定挂载时宿主机路径不存在会静默创建空目录，权限不匹配（如postgresql要求uid=999、700权限）导致写入失败；命名卷数据实际存于wsl2/hyperkit虚拟机内部，不可直访宿主机文件系统。
数据没丢，是根本没挂进去——Docker Desktop 的卷挂载失败，90% 情况下不是 Docker 问题，而是路径、权限或挂载方式在 macOS/Windows 上被系统层“悄悄拦截”了。
docker volume ls 看得到卷，但容器里 /var/lib/postgresql/data 是空的
这是最典型的“挂载假象”。docker volume ls 显示卷存在，docker inspect 也显示挂载配置正确，但容器内目标目录仍是空的，说明挂载点未生效。常见原因：
- 宿主机路径在 Docker Desktop 设置中未勾选共享（macOS：Preferences → Resources → File Sharing；Windows：Settings → Resources → File Sharing）
- 路径含中文、空格或符号（如
/Users/张三/pgdata），Docker Desktop 无法解析，静默降级为匿名卷 - 使用了绑定挂载（
-v /host/path:/container/path），但宿主机路径实际不存在（Docker Desktop 不报错，自动创建空目录并挂载，但权限为 root，容器内 postgres 用户写不进）
验证方法：docker exec -it 容器名 ls -la /var/lib/postgresql/data。如果输出显示是空目录且属主为 root，基本可断定挂载失败或权限错配。
Windows/macOS 下绑定挂载权限始终不对（postgres 启动失败 /var/lib/postgresql/data: Permission denied）
Docker Desktop 在非 Linux 环境下不直接透传 UID/GID，绑定挂载时宿主机文件权限不会自动映射到容器内用户。PostgreSQL 镜像要求 /var/lib/postgresql/data 目录权限为 700 且属主 UID=999，而 Windows/macOS 默认创建的目录属主是当前用户（UID ≠ 999），且权限宽松（如 755）。
- macOS：用
sudo chown -R 999:999 /Users/xxx/pgdata+chmod 700 /Users/xxx/pgdata，再启动容器 - Windows：不建议直接改 NTFS 权限适配 UID，应改用命名卷（
-v pgdata:/var/lib/postgresql/data），由 Docker Desktop 自动管理底层存储和权限 - 通用规避法：启动时加
--user 999:999强制容器以指定 UID 运行，但需确认镜像支持（PostgreSQL 官方镜像支持）
docker save/load 后数据全没了，但 volume create 和 run 命令都写了
这是迁移场景下的经典误判。docker save 只打包镜像，docker load 只恢复镜像，**完全不涉及任何 volume 数据**。即使你用了 docker volume create pgdata 并在 docker run 中挂载，新机器上这个名为 pgdata 的卷也是空的——它只是个新创建的、同名但无内容的壳。
- 命名卷数据实际存于 Docker Desktop 虚拟机内部（macOS 是
~/Library/Containers/com.docker.docker/Data/vms/0/data/docker/volumes/；Windows 是 WSL2 的\wsl$docker-desktop-data ersion-pack-datacommunitydocker olumes），无法随镜像导出 - 真正要迁移数据，必须手动备份卷内容：
docker run --rm -v pgdata:/volume -v $(pwd):/backup alpine tar cvf /backup/pgdata.tar -C /volume . - 恢复时反向操作：
docker run --rm -v pgdata:/volume -v $(pwd):/backup alpine tar xvf /backup/pgdata.tar -C /volume
重启 Docker Desktop 后卷数据“变旧”或“回滚”了
这不是数据丢失，是 Docker Desktop 的 WSL2 或 HyperKit 虚拟机快照机制在作祟。某些版本（尤其是 macOS 4.30+、Windows 4.28+）在异常退出后，会从上次已知一致状态恢复虚拟机磁盘，导致你刚写入卷的数据被“倒带”。
- 检查是否启用了 “Start Docker Desktop when you log in” + “Automatically start containers on daemon startup” —— 这类自动行为可能触发未完成的写入状态恢复
- 临时规避：每次写入关键数据后，执行
docker run --rm -v pgdata:/data alpine sh -c "sync && echo 'flushed'"强制刷盘 - 根治办法：关闭 Docker Desktop 的自动恢复功能（Settings → General → Uncheck “Start Docker Desktop when you log in”），改用手动启停 + 显式
docker stop容器后再退出 Desktop
最易被忽略的一点：Docker Desktop 的卷数据并不在你 macOS 的 /var/lib/docker 下，也不在 Windows 的 C:Program FilesDocker 下——它藏在虚拟机内部，不可直连、不可用 Finder/Explorer 浏览，所有操作必须通过 docker volume 命令或容器间接进行。想当然地去宿主机文件系统里找 pgdata 目录，注定扑空。
