bind mount 排错核心是路径存在性、权限一致性、挂载时机：宿主机路径须真实存在（docker 不自动创建父目录），相对路径以 docker-compose.yml 为准，权限需匹配容器用户，挂载会覆盖容器内原路径内容。
Bind Mount 排错核心就三点：路径存在性、权限一致性、挂载时机是否正确。不是加了 -v 就一定生效，很多问题出在细节上。
路径不存在或拼写错误
宿主机路径必须真实存在，Docker 不会自动创建父目录（比如 /data/conf 但 /data 本身不存在）。
- 运行前先检查：
ls -ld /your/host/path，确认目录存在且可读 - Docker Compose 中的相对路径（如
./config）是相对于docker-compose.yml所在目录，不是当前 shell 路径 - Windows/macOS 用户注意路径分隔符和大小写——Linux 容器内路径区分大小写，
/Config和/config是两个目录
权限不匹配导致容器无法读写
容器内进程以非 root 用户运行时（推荐做法），宿主机目录权限若未开放，就会报 Permission denied 或 ENOENT（看似文件不存在，实为无权访问）。
- 查容器运行用户：
docker inspect myapp | jq '.Config.User' - 查宿主机目录属主：
ls -ld /host/path - 临时验证可用：
sudo chown -R 1001:1001 /host/path（假设容器用 UID 1001） - 生产环境建议用
user:+group_add:配合宿主机组 ID，而非粗暴chmod 777
挂载后内容被覆盖或不可见
Bind Mount 会把宿主机目录“原样盖上去”，如果容器镜像里该路径已有文件（比如 /app/config.yaml），挂载后这些文件就不可见了——这是设计行为，不是 bug。
- 想保留镜像默认配置？先复制出来：
docker run --rm -v $(pwd)/config:/tmp/out alpine cp /app/config.yaml /tmp/out/ - 挂载空目录时，容器内看到的是空目录；挂载含文件的目录，容器内直接看到那些文件
- 避免挂载到容器内关键系统路径（如
/etc、/usr/bin），极易引发启动失败
Windows/macOS 文件共享配置异常
桌面版 Docker Desktop 默认只共享特定目录（如 /Users、C:\Users），挂载其他路径会静默失败或提示 permission denied。
- macOS：打开 Docker Desktop → Preferences → Resources → File Sharing，添加你的项目根目录
- Windows：同样进 Settings → Resources → File Sharing，确认驱动器已勾选（如
C:） - 改完需重启 Docker Desktop，否则新设置不生效
