要在 macOS 上安全地更改 Compose 绑定挂载，首先确定现有的宿主机文件夹及其服务的容器路径。在编辑 Compose 之前将文件复制到新的 Mac 文件夹，然后验证解析后的挂载并重新创建受影响的服务。绑定挂载指向一个宿主机路径；更改该路径并不会移动或删除原始文件。Docker 的绑定挂载文档还解释了挂载可能会隐藏容器目标位置中已存在的文件。

了解挂载控制哪些文件

Compose 绑定挂载将 Mac 上的路径连接到容器内部的路径。例如，./data:/var/lib/example 会使 Compose 文件旁边的 data 目录在容器内的 /var/lib/example 处可用。容器对该挂载进行的写入操作可以更改 Mac 文件，因为绑定挂载默认是可读写的。Mac 文件夹是您需要保留的数据；容器目标位置是应用程序期望看到它的地方。

这与命名卷（例如 db-data:/var/lib/example）不同。命名卷由 Docker 存储和管理，而绑定挂载使用宿主机目录。将一种更改为另一种属于存储迁移，而不仅仅是路径编辑。不要以为重新创建容器就会在它们之间复制文件。Docker 的存储文档描述了这种区别。

将现有文件复制到新的 Mac 文件夹

在更改 Compose 文件之前，如果服务可能会写入数据，请先停止该服务。在终端中运行 docker compose stop app，将 app 替换为 Compose 服务名称。这可以减少在复制过程中新旧文件夹发生数据不一致的几率。检查 Compose 文件和任何覆盖配置，以确认当前的准确源路径和目标路径；避免仅根据容器的可见目录进行猜测。

例如，如果当前源路径为 ~/Projects/Old App/data，而新源路径应为 ~/Projects/New App/data，请创建目标目录并使用 macOS 的标准 rsync 命令复制内容：

mkdir -p "$HOME/Projects/New App/data"
rsync -a "$HOME/Projects/Old App/data/" "$HOME/Projects/New App/data/"

末尾的斜杠表示“复制此目录的内容”。引号可保护这些示例路径中的空格不受 macOS 默认 shell（zsh）的影响。此命令会将文件合并到目标位置，且不会删除仅存在于目标位置的文件。在继续操作之前检查目标位置。如果数据很重要，还请保留独立备份；复制并不能替代备份。

更新绑定挂载并防范拼写错误

当您希望源路径缺失时阻止启动而不是静默生成一个空文件夹时，建议在目录挂载中优先使用 Compose 长语法：

services:
  app:
    volumes:
      - type: bind
        source: ./data
        target: /var/lib/example
        bind:
          create_host_path: false

在这里，对于本地 Compose 运行时，./data 是相对于 Compose 文件的父目录解析的。将其更改为预期的 Mac 相对或绝对路径，但如果应用程序应继续使用 /var/lib/example，则保持 target 不变。当源路径缺失时，Compose 的短语法会创建一个宿主机目录；而带有 create_host_path: false 的长语法可以避免这种回退行为。请参阅 Compose 服务参考。

如果您选择包含空格的绝对路径，请为 YAML 字符串加上引号，例如 source: "/Users/sam/Projects/New App/data"。将 sam 替换为您的 Mac 帐户的实际主目录名称。在 YAML 中将源路径保留为字面路径；shell 引号规则适用于终端命令，而不适用于 YAML 值。

检查解析后的路径，然后重新创建服务

在包含 Compose 文件的目录中，检查 Compose 将使用的配置：

docker compose config

检查 app 服务的绑定源是否解析为新文件夹，且其目标是否仍为 /var/lib/example。如果您使用多个 Compose 文件，请记住路径基于指定的第一个文件；Compose CLI 参考记录了此行为。如果解析出的源路径不符合预期，请在启动容器之前停止并修正文件。

重新创建服务，以便正在运行的容器能够应用更改后的挂载：

docker compose up -d --force-recreate app
docker compose ps app

Compose 文档指出，当配置发生更改时 up 会重新创建容器，而 --force-recreate 则明确执行该操作。确认服务正在运行，然后在删除或重命名旧文件夹之前，检查应用程序预期所需的文件或数据。除非您亲自删除，否则旧目录仍会保留在 Mac 上。请保留它，直到您确认新源路径正确无误且应用程序运行正常。

如果挂载在 Docker Desktop for Mac 上失败

Docker Desktop 在 Linux 虚拟机中运行容器，并协调对 Mac 文件的访问。其默认共享目录包括 /Users、/Volumes、/private、/tmp 和 /var/folders；如果源路径位于可用共享位置之外，可能需要在 Docker Desktop 的 Settings > Resources > File sharing 中添加。Docker 的 Desktop 设置文档介绍了此控件，并指出文件权限依然起作用。

挂载失败应该触发路径和共享检查，而不是删除旧副本。如果新目录为空，请验证解析出的 source、复制是否将文件放置在了预期的目录层级，以及 Docker Desktop 是否能够访问该 Mac 位置。不要使用 docker compose down -v 作为绑定挂载的修复步骤：更改绑定源时完全没有必要这样做，而且它可能会删除项目使用的命名卷。

安全完成整个过程其实很简单：验证新的 Mac 文件夹包含所需文件，确认 Compose 正确解析到该文件夹及预期的容器目标，然后在废弃原始副本之前测试重新创建的服务。

来源