Volume是Docker官方推荐的生产环境首选持久化方式，独立于容器生命周期，由Docker全权管理路径与权限，支持备份迁移、跨容器共享，并需用docker volume create与--mount显式操作以保障可控性。
Volume 是 Docker 官方推荐、生产环境首选的数据持久化方式，它独立于容器生命周期，不随 docker rm 删除而消失，也不依赖宿主机目录结构，天然规避权限、路径不存在、Windows/macOS 文件系统性能等问题。
创建和挂载命名卷时，docker volume create 和 --mount 是关键组合
命名卷（named volume）由 Docker 全权管理路径和权限，你只需关心名字和容器内挂载点。不要用 -v myvol:/path 这种简写形式去“顺手”挂载——它虽能自动创建卷，但无法指定驱动或选项；真正需要可控性时，必须显式创建 + 显式挂载：
-
docker volume create --driver local --opt type=nfs --opt o=addr=192.168.1.100,rw mynfs：挂载 NFS 卷（需提前配置好 NFS 服务） -
docker run -d --name db --mount source=myvol,target=/var/lib/postgresql/data postgres：使用--mount挂载，语义清晰、支持更多选项（如readonly、volume-opt） - 避免混用：
-v和--mount对同一卷的挂载行为一致，但--mount更严谨，尤其在 Swarm service 场景下是唯一支持方式
挂载空卷到已有容器目录时，原内容会被复制进卷中
这是最容易被忽略的行为：当你第一次把一个**空命名卷**挂载到容器里一个已有文件的路径（比如 /usr/share/nginx/html），Docker 会把该路径下原本的文件（如 index.html）**一次性复制进卷中**，之后容器再读写的都是卷里的副本。这意味着：
- 首次启动时看到的是镜像自带文件，但后续修改都落在卷里，重启后仍保留 如果误删了卷，这些初始文件就永久丢失，无法靠重拉镜像恢复（因为镜像层不会重新覆盖卷）
- 若想跳过复制、让卷始终为空，可在挂载前手动清空目标目录（如用
docker exec -it container sh -c "rm -rf /path/*"），或改用 bind mount 控制源内容
卷的生命周期管理必须主动介入，否则会越积越多
Docker 不会自动清理“未被任何容器引用”的卷，docker volume ls 列出的卷可能大部分已废弃。长期运行后容易占满 /var/lib/docker/volumes/ 所在磁盘：
-
docker volume prune：删除所有未被使用的卷（执行前务必确认没有遗漏的备份卷） -
docker volume inspect myvol：查看卷实际存储路径（通常是/var/lib/docker/volumes/myvol/_data），可直接在宿主机上做 rsync 备份或 du 查大小 - 不要依赖
docker system prune -a清理卷——它默认跳过 volumes，加--volumes才会删，风险极高
真正的麻烦往往不在创建，而在卷被多个容器以不同读写模式共享时的竞态，或跨平台迁移时驱动不兼容——这些细节一旦出错，数据就卡在卷里出不来，比 bind mount 更难调试。
