匿名卷由Docker自动创建并分配随机哈希名，生命周期独立于容器，删容器不自动删卷；需用docker volume prune手动清理 dangling 卷。
匿名卷自动创建但不自动清理，删容器不等于删数据
用 docker run -v /data 启动容器时，Docker 会自动生成一个匿名卷，名字是一串随机哈希（比如 7f3b9a1e5c2d...），挂载到容器内 /data。这个卷的生命周期和容器**不绑定**：即使你执行 docker rm my-container，卷依然留在 /var/lib/docker/volumes/ 下，只是没人引用它了。
常见错误现象：
- 反复
docker run+docker rm，磁盘空间悄悄涨——因为旧匿名卷没被清理 - 误以为加了
--rm就能自动清数据，其实只有带--rm的容器退出时才会顺手删掉它挂载的匿名卷（注意：仅限该次运行所创建的匿名卷）
实操建议：
- 查残留卷：
docker volume ls -f dangling=true - 批量清理：
docker volume prune（确认无用后再执行） - 开发调试临时缓存可用，但别用于数据库、用户上传等关键路径
命名卷必须显式创建，名称即标识，跨容器共享才可靠
命名卷不是“高级功能”，而是把数据管理权交还给你。先 docker volume create --name pg-data，再 docker run -v pg-data:/var/lib/postgresql/data postgres。这时 pg-data 就是宿主机上一个可识别、可检查、可备份的实体。
使用场景：
- PostgreSQL/MySQL 容器重建后仍要保留数据
- 多个服务（如 web + log-shipper）需要读写同一份日志目录
- CI/CD 中需在不同阶段复用构建缓存或测试结果
关键细节：
-
docker volume inspect pg-data能看到真实Mountpoint路径，但**不要直接编辑该目录**——属主、权限、文件锁都可能被容器进程锁定 - 命名卷不能在
Dockerfile里声明，只能在运行时或docker-compose.yml顶层volumes:块中定义 - 删除前务必确认：没有容器正在使用它，否则
docker volume rm会报错unable to remove volume: device or resource busy
docker-compose.yml 里顶层 volumes 不是必须项，但省去手动 create 步骤
很多人以为 volumes: 写在 services 外面是“规范写法”，其实它只是预定义一批命名卷，避免每次 docker-compose up 前还要手动 docker volume create。它和 service 内的 volumes 字段完全解耦。
示例片段：
volumes: redis_cache: app_uploads: <p>services: web: volumes:</p><ul><li>app_uploads:/var/www/uploads worker: volumes:</li><li>app_uploads:/app/uploads</li><li>redis_cache:/data
这样写的好处：
-
app_uploads可被web和worker同时挂载（注意应用层是否支持并发写） - 下次
docker-compose down后，redis_cache和app_uploads依然存在 - 不用记一堆
docker volume create命令，所有卷名集中在一处，方便团队对齐
容易踩的坑：
- 顶层声明了
db-data，但 service 里写成- db_data:/var/lib/mysql（下划线 vs 连字符），导致新建一个匿名卷而非复用命名卷 - 用
docker-compose down -v会连带删掉顶层声明的所有卷——生产环境慎用
绑定挂载（bind mount）不是卷，但它最透明也最危险
docker run -v /home/user/conf:/etc/nginx/conf.d 这种写法叫绑定挂载，它直接把宿主机路径映射进容器。它不属于 Volume 类型，但常被拿来对比。它的特点是：路径可见、修改实时生效、权限由宿主机决定。
为什么说它“最危险”：
- 容器内进程可直接改宿主机任意目录（比如误挂
/或/etc） - Windows/macOS 上通过 Docker Desktop 的 WSL2/Hyper-V 层转发，I/O 性能明显低于命名卷
- 路径硬编码，跨机器部署时容易失效（比如本地
/Users/xxx在 CI 服务器上根本不存在）
适用边界很窄：
- 开发阶段热重载代码（
./src:/app/src） - 注入单个配置文件（
./nginx.conf:/etc/nginx/nginx.conf:ro） - 绝对不要用于数据库目录、日志聚合目录、或任何可能被多进程并发写的路径
真正容易被忽略的一点：命名卷默认以 root 属主挂载，而绑定挂载继承宿主机文件权限。如果容器内程序以非 root 用户运行（如 USER 1001），绑定挂载可能因权限不足写入失败，命名卷则不会——这是权限问题排查的起点。
