必须先在Docker Desktop的File Sharing中显式添加宿主机绝对路径（如/Users/yourname/project），否则-v挂载必报“Mounts denied”；添加后需Apply & Restart，且路径末尾不可带斜杠，验证须用mount | grep确认osxfs类型挂载。
必须先在 Docker Desktop 的 File Sharing 设置里显式添加路径，否则任何 docker run -v 挂载都会失败，且只报模糊的 “Mounts denied”，不提示具体原因。
怎么确认宿主机路径是否已被 Docker Desktop 允许挂载
打开 Docker Desktop → Preferences → Resources → File Sharing，检查你要用的绝对路径（比如 /Users/yourname/project）是否已在列表中。如果没出现，说明它当前不可用——Docker 不会自动继承 Finder 或终端里的访问权限，也不会读取系统级共享设置。
常见误操作包括：只加了父目录（如加了 /Users/yourname 却想挂载 /Users/yourname/project/src），或路径拼写大小写错误（macOS 文件系统默认不区分大小写但 Docker 会严格校验）。
添加后务必点 Apply & Restart，否则改动不生效。重启完成后，Docker 才真正获得该路径的 hostfs 访问能力。
为什么 docker run -v 挂载时路径末尾不能带斜杠
这是 macOS 上一个容易被忽略的细节：/Users/yourname/project/ 和 /Users/yourname/project 在语义上不同。Docker 会把末尾带 / 的路径当作“指向一个文件”来解析，导致挂载失败并报 No such file or directory，即使目录真实存在。
正确做法是始终使用无尾斜杠的绝对路径：
- ✅ 正确：
docker run -v /Users/yourname/project:/app nginx:alpine - ❌ 错误：
docker run -v /Users/yourname/project/:/app nginx:alpine
这个规则对 --mount 同样适用；且 --mount 还更严格：若宿主机路径不存在，它直接报错退出，而 -v 会静默创建空目录——这反而容易掩盖路径未共享的问题。
挂载后如何快速验证是否成功
别只靠 ls /app 看有没有内容，那可能只是容器镜像里原本就有的文件。真要确认是挂载进来的，得查底层挂载来源：
- 进入容器：
docker exec -it sh - 运行：
mount | grep app
输出中应明确包含宿主机路径信息，例如：
osxfs on /app type osxfs (rw,nosuid,nodev,relatime)
如果看到的是 overlay 或 ext4 类型，说明挂载根本没生效，还在用容器自己的文件系统。这时候回退检查 File Sharing 列表和路径拼写，比调容器配置更有效。
最常被跳过的一步，是以为「路径存在 + 命令能跑通」就等于挂载成功——其实 Docker Desktop 的 File Sharing 是一道硬性闸门，它关着，后面所有挂载操作都是空转。
