默认卷名机制为“项目目录名_卷定义名”，如order-api_db-data；若多项目目录名相同或-p参数未同步，易导致卷复用和数据串扰，故必须显式设置name字段并结合环境变量动态生成合规名称。
docker-compose.yml 里不写 name 就会串数据
默认情况下，Docker Compose 用当前目录名 + 下划线 + 卷定义名拼出卷名，比如项目目录叫 order-api、卷定义叫 db-data，最终卷名就是 order-api_db-data。问题在于：一旦两个项目目录名相同（CI 构建临时目录、多人本地 clone 路径不一致）、或你用 -p 指定不同项目名但忘了同步卷配置，就会意外复用同一个卷。
更危险的是，如果你在多个 docker-compose.yml 中都定义了 db-data: 却没写 name:，它们可能各自生成不同前缀的卷，但只要某次执行时项目名碰巧一样，数据就混了。
- 永远在
volumes块中显式声明name字段，哪怕只是加个固定前缀 - 别依赖
docker-compose --project-name自动带前缀——它只影响默认卷名，不覆盖已声明的name - CI 流水线里禁止用
$(pwd)或basename $(pwd)当项目名，改用环境变量如CI_PROJECT_ID
用环境变量动态生成 name 实现多环境隔离
硬编码卷名（如 order-prod-db）在开发/测试/预发环境里会失效。正确做法是把关键维度抽成变量，在 docker-compose.yml 里组合：
version: '3.8'
services:
db:
image: postgres:15
volumes:
- db-data:/var/lib/postgresql/data
volumes:
db-data:
name: ${PROJECT_NAME:-default}-${ENV:-dev}-postgres-data
driver: local启动时传入变量：PROJECT_NAME=payment-gw ENV=staging docker-compose up -d，生成的卷名就是 payment-gw-staging-postgres-data。
-
${VAR:-fallback}语法确保变量未设置时不报错，但 fallback 值也要符合命名规则（不能以-开头） - 避免在
name里拼接服务名（如${SERVICE_NAME}）——Compose 不支持服务级变量注入到 volume name - 所有变量应在 CI 配置或
.env文件里统一管理，禁止散落在 shell 脚本里
校验卷名是否合法，否则 docker volume create 直接失败
Docker 对卷名有严格字符限制：只能含小写字母、数字、-、_；必须以字母或数字开头结尾；长度 ≤63 字符。违反任一条件，docker volume create 或 docker-compose up 会报错：invalid volume name 或 invalid reference format。
常见踩坑点：
- 环境变量值含大写字母（如
ENV=PROD）→ 卷名出现P→ 失败 - 项目名含下划线（如
user_management）→ 拼出user_management-dev-db→ 合法，但部分平台（K8s）对下划线支持弱 - 过长组合：当
PROJECT_NAME+ENV+ 固定后缀 > 63 字符 → 创建失败
建议在 CI 的 pre-deploy 步骤加一行校验：
echo "${PROJECT_NAME}-${ENV}-postgres-data" | grep -E '^[a-z0-9]([a-z0-9_-]{0,61}[a-z0-9])?$' > /dev/null || (echo "volume name invalid" && exit 1)Mac 上 Docker Desktop 的 Volume 存储路径不可见，别试图手动清理
Docker Desktop for Mac 把 volume 数据存在虚拟机内部（/var/lib/docker/volumes/），宿主机文件系统不可直接访问。你执行 docker volume ls 看到的卷名，和实际磁盘路径没有直观映射关系。
这意味着：
- 不要用 Finder 打开
~/Library/Containers/com.docker.docker/Data/vms/找 volume 文件——路径结构加密且随时可能变 - 清理必须走
docker volume rm，而不是删宿主机文件夹 - 备份 volume 数据只能通过容器导出：
docker run --rm -v myapp-prod-db-data:/data -v $(pwd):/backup alpine tar czf /backup/db.tar.gz -C /data .
真正容易被忽略的是：Docker Desktop 的资源限制（内存/CPU）会影响 volume I/O 性能，尤其当多个项目同时读写大量小文件时。如果发现 docker-compose up 启动慢、日志刷屏卡顿，先检查 Docker Desktop 设置里的资源分配，而不是怀疑卷名冲突。
