Docker容器挂载目录到已有/var/www/app路径时文件不可见问题

问题根因 #

这是Docker Desktop for Mac 4.8.x版本分支的典型挂载层冲突问题，触发逻辑完全匹配你描述的现象：

• 目标路径/var/www/app是镜像构建阶段就存在的预置目录，内部自带生产环境构建产物
• 出问题的用户本地首次启动该镜像容器时，曾出现过挂载配置未加载、启动时序异常的情况，Docker自动为该预置路径生成了空的匿名卷，并写入了本地挂载缓存
• 后续即使compose配置正确写入了本地目录绑定挂载规则，Docker仍会将旧的空匿名卷叠加在绑定挂载层的上层：写操作会透传到底层绑定挂载（所以你在容器内创建的文件能同步到宿主机），但读目录元数据时会优先命中上层空匿名卷的缓存（所以ls命令始终显示目录为空）。
  修改为镜像内不存在的新路径时挂载正常，正是因为新路径没有对应的遗留匿名卷，不会出现挂载层叠加冲突。

排查验证 #

在出问题的设备上执行以下操作即可确认问题：

1. 停掉当前运行的异常容器
2. 启动容器后执行docker inspect <异常容器ID>，在返回的Mounts字段中，能看到/var/www/app路径下同时存在两条挂载记录：一条是你配置的本地目录绑定挂载，另一条是随机哈希ID的匿名卷挂载，匿名卷的挂载优先级更高。
3. 执行docker volume ls -f dangling=true，能看到上述随机ID对应的悬空匿名卷记录。

修复步骤 #

按顺序操作，某一步执行完验证挂载正常即可停止：

• 第一步：在docker-compose.yml所在目录执行命令，清理当前项目关联的遗留容器和匿名卷：

docker-compose down -v

注意：这里的-v参数只会删除当前compose项目关联的匿名卷，不会删除你手动声明的具名卷，也不会修改宿主机本地的代码文件，没有数据丢失风险。
执行完重新docker-compose up -d启动容器，验证挂载是否正常。

• 第二步：如果第一步无效，全局清理本地所有无用的悬空匿名卷：

docker volume prune -f

执行完重启容器验证。

• 第三步：如果前两步都无效，打开Docker Desktop设置 -> Resources -> File Sharing，确认存放项目代码的父目录（比如/Users/xxx/develop）已经加入共享列表，不要只单独添加项目的深层子目录，避免目录遍历权限异常。
• 第四步：极端情况下可以打开Docker Desktop设置 -> Troubleshoot，执行Restart Docker Desktop，仍不生效就执行Clean / Purge data清理Docker本地缓存即可，该操作只会清除Docker存储的镜像、容器、卷缓存，不会影响宿主机文件。

原因补充 #

其他成员使用正常仅新成员出现问题，核心差异是启动时序：其他成员首次启动项目时compose挂载配置正常加载，Docker不会自动为预置目录生成匿名卷；新成员首次启动时大概率出现过配置漏写、挂载加载报错未察觉的情况，自动生成的空匿名卷留在本地缓存中，才触发了挂载层冲突。

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