容器重建后数据丢失主因是挂载未生效：命名卷未预创建导致每次启用新卷、挂载路径错配、宿主机权限不足或Windows共享未开启，须通过docker volume inspect和docker inspect验证实际挂载状态。
容器重建后数据丢失，不是 Docker 出了 bug，而是挂载根本没生效——绝大多数情况，docker run 命令里写的 -v 没真正把数据落到宿主机卷上。
命名卷没显式创建，导致每次重建都用新卷
很多人写 docker run -v mydata:/var/lib/mysql mysql:8，以为名字写了就“绑定”了。其实 Docker 会检查名为 mydata 的卷是否存在：不存在就自动创建一个空卷，旧数据完全不受影响。下次再 docker run，只要没删卷，它还是用同一个 mydata；但如果你误用了 docker run --rm 或脚本里带 --volumes，或者压根没注意卷名拼错（比如 mydate），那新容器就进了全新匿名卷。
- 启动前先手动创建：
docker volume create mydata - 确认是否真在用这个卷：
docker volume inspect mydata看Mountpoint路径是否存在且非空 - 别依赖“命令里写了名字”就放心——用
docker ps -a查容器的Mounts字段，确认挂载源确实是mydata，不是local类型加一串随机 ID
Windows 下挂载报 user declined directory sharing
这是 Docker Desktop for Windows 特有报错，和路径写法、权限无关，纯粹是 Docker Desktop 的共享白名单没开。你写的 -v D:\data:/data 语法完全正确，但 Docker 引擎在 WSL2 里根本拿不到这个盘符的访问授权。
- 打开 Docker Desktop → Settings → Resources → File Sharing
- 把
D:（或具体目录如D:\data）加进共享列表，点 Apply & Restart - 重启后仍失败？检查 WSL2 发行版是否已关机：
wsl --shutdown再重试 - 避免用 OneDrive 同步目录做挂载点——即使加了共享，OneDrive 的文件锁机制也会导致挂载后目录为空或只读
挂载路径对不上容器内默认数据目录
PostgreSQL 必须写入 /var/lib/postgresql/data，MySQL 是 /var/lib/mysql，Neo4j 是 /data……这些路径由镜像 Dockerfile 里的 VOLUME 和启动脚本固化，改不了。挂载时少一个 /data 后缀，或者多套一层 /app/data，数据就全掉进容器可写层里，docker rm 一执行，彻底清零。
- 查官方镜像文档确认路径，别凭经验猜。例如 PostgreSQL 官方镜像明确要求挂载到
/var/lib/postgresql/data - 启动后立刻验证：
docker exec -it 容器名 ls -la /var/lib/postgresql/—— 如果data是个空目录（不是挂载点），说明挂载失败；如果是挂载点，ls -la /var/lib/postgresql/data应能看到PG_VERSION等文件 - 用
docker inspect 容器名查Mounts，确认Destination字段和镜像要求完全一致，字符不能差一个
绑定挂载时宿主机目录权限不匹配
Linux 容器内进程（如 mysql 用户 UID=999）无法写入宿主机目录，就会静默退回到容器可写层。现象是：容器能启动、服务能连，但建库建表后重启就消失——因为所有操作实际发生在临时层。
- 查容器内用户 UID：
docker exec 容器名 id -u mysql（或看镜像文档，MySQL 通常为 999，PostgreSQL 为 999，MongoDB 为 999） - 修复宿主机目录：
sudo chown -R 999:999 /host/path+sudo chmod -R 700 /host/path（PostgreSQL 要求严格 700） - 命名卷不用操心这个——Docker 自动以对应 UID 初始化
_data目录，这是它比绑定挂载更稳的核心原因之一
最易被忽略的一点：挂载是否生效，不能只看命令有没有报错，必须进容器验证目标路径是不是挂载点、有没有历史数据残留。很多问题表面是“数据丢了”，实际是“从来就没存进去”。
