容器停止后数据卷数据完全保留，仅当显式执行 docker volume rm 或清空宿主机路径（bind mount）时才会丢失；Docker Desktop 与原生 Docker 行为一致，volume 生命周期独立于容器。
容器停止后，数据卷里的数据完全不受影响——只要没手动删卷，数据就一直在。 Docker Desktop 和 Linux 原生 Docker 在数据卷行为上完全一致，不存在“Desktop 特有丢失风险”。真正决定数据存留的，是卷类型（volume 还是 bind mount）和你是否执行了 docker volume rm 或清空宿主机路径。
volume 类型的数据卷：停容器 ≠ 删数据
用 docker volume create mydata 创建的命名卷，或运行容器时自动创建的匿名卷（如 -v /data），其数据默认存放在 /var/lib/docker/volumes/ 下（Docker Desktop 实际通过 Linux 子系统或 VM 映射到 macOS/Windows 主机，但路径对用户透明）。这类卷的生命周期由 Docker 管理，与任何容器无关。
- 容器
stop、start、restart：数据毫发无损 - 容器
rm（即使加-v）：只删容器，不删 volume；docker rm -v中的-v仅影响 匿名卷，且仅当该卷未被其他容器引用时才可能被清理 - 必须显式执行
docker volume rm mydata才会真正删除数据 - Docker Desktop 重启、甚至重装客户端，只要底层 VM 或 WSL2 虚拟磁盘没被重置，
volume数据就还在
bind mount 类型的挂载：停容器也不丢，但依赖宿主机路径
用 -v /Users/you/app:/app 这种方式挂载的是宿主机真实路径，Docker Desktop 只是做了路径映射（macOS 是直接访问，Windows 是通过 WSL2 文件系统桥接）。它的存留逻辑和普通文件一样：
- 容器停止或删除，宿主机路径里的文件照常存在
- 但如果你手动删了
/Users/you/app，或者重装系统清空了用户目录，数据就没了 - Docker Desktop 的文件共享设置（比如 macOS 的 File Sharing 白名单）若没包含该路径，容器根本启动不了，会报错
invalid mount config - Windows 上用
C:\data挂载时，注意路径权限——WSL2 默认对 Windows 盘符是只读的，需在 Docker Desktop 设置里开启Enable integration with Windows Subsystem for Linux
容易误删数据的两个操作场景
很多人以为“删容器就等于删数据”，其实是混淆了可写层和数据卷。真正危险的操作只有这两个：
- 执行
docker system prune -a且没加--volumes以外的确认开关：它默认不删 volume，但会删所有 未被任何容器引用的匿名卷（即没名字、也没被docker run -v xxx:/path显式声明的卷） - 在 Docker Desktop GUI 点击 “Reset to factory defaults”：这个操作会彻底清空
/var/lib/docker下所有内容，包括全部volume、镜像、网络——相当于把调料仓库连地基一起推平
最常被忽略的一点：Docker Desktop 的 volume 并非“看不见就等于不存在”。docker volume ls 看不到，不代表数据丢了——可能是卷名拼错了，也可能是你用的是 bind mount 却在查 volume 列表。先确认挂载方式，再查对应位置，比反复重建容器靠谱得多。
