让我来逐一解答你的这两个技术疑问：

1. 为何不推荐使用匿名卷？ #

你提到匿名卷比绑定挂载（比如/tmp/cache:/cache）更安全，这点确实合理——绑定挂载直接映射宿主机具体路径，多容器共用时易出现数据冲突或误改风险。但匿名卷的缺点也很明显，导致它通常不被推荐：

• 追踪与管理成本高：匿名卷在宿主机的路径是/var/lib/docker/volumes下的随机目录，通过docker volume ls看到的只是一串无意义ID，很难直接关联到对应容器，备份、迁移或清理数据时会非常麻烦。
• 复用性差：匿名卷没法像命名卷那样被明确指定给其他容器使用，若想复用旧容器的匿名卷数据，只能依赖--volumes-from这种绑定容器的方式，灵活性极低。
• 排查难度大：当多个容器都用匿名卷时，一旦出现数据问题，很难快速定位到对应卷进行排查，大幅增加运维成本。

2. Dockerfile中的VOLUME /build与docker-compose.yml中的volumes: - /build是否等效？是否存在需同时配置两者的场景？ #

这两种配置并不完全等效，作用范围和优先级有明显区别：

• 作用范围不同：
  • Dockerfile里的VOLUME /build是镜像级声明，所有基于该镜像创建的容器，都会自动在/build挂载匿名卷，这个设置会被镜像的所有使用者继承，属于镜像的默认行为。
  • docker-compose.yml中的volumes: - /build是容器级配置，仅对当前compose服务的容器生效，不会影响其他基于同一镜像创建的容器。
• 挂载效果类似但无需重复配置：单独用任意一种配置，最终容器的/build都会挂载匿名卷，但同时配置不会产生额外效果——Dockerfile的声明已经确保了挂载，compose的配置只是重复操作。

至于是否需要同时配置？一般完全不需要，反而会造成配置冗余和混淆。只有极端场景可能用到：比如你希望强制确保即使镜像被修改（移除了VOLUME声明），compose服务的容器依然会在/build挂载匿名卷，但这种情况非常少见，通常更推荐统一在镜像或compose中配置即可。

内容的提问来源于stack exchange，提问作者overexchange