Docker将宿主机不存在的路径静默创建为目录，导致预期挂载的文件“消失”；本质是-v不校验路径类型，需用ls -ld确认宿主机路径真实类型（-为文件、d为目录）并前置确保其存在且类型匹配。
挂载后宿主机文件变成空目录，本质是 Docker 把你指定的 host_path 当成了目录而非文件来处理——它不会报错，但会静默创建同名空目录并挂载进去，导致你原文件“消失”了。
为什么 -v 会把文件挂成空目录
Docker 的 -v 挂载机制对路径类型不做预检：只要宿主机路径不存在，它就按目录创建；如果存在但类型不匹配（比如你写的是 /path/to/config.json，而实际那里是个目录），Docker 仍会尝试挂载，但行为不可控。更常见的是：你本意挂一个配置文件，却误写了路径末尾带斜杠（如 /conf/config.json/），或宿主机上同名路径恰好是目录而非文件。
- Windows 用户尤其容易中招：资源管理器里双击打开过 JSON/YAML 文件，系统可能自动创建同名文件夹用于存放关联内容（如缩略图、元数据），导致
config.json实际被覆盖为config.json/目录 - Docker Compose 中用
./config.yaml:/app/config.yaml时，若当前目录下config.yaml是个目录（不是文件），Compose 不校验，直接挂载该目录 -
docker run -v命令中，冒号左边路径若在宿主机不存在，Docker 默认创建为目录，不会警告你“你本想挂文件，但我建了个目录”
怎么确认挂载源到底是文件还是目录
别猜，直接查。在宿主机终端执行：
ls -ld /your/host/path
看输出第一列开头字符：- 表示普通文件，d 表示目录，l 表示软链接。如果是目录但你期望是文件，问题就定位了。
- Windows PowerShell 中用
Get-Item C:\path\to\file | ForEach-Object {$_.GetType().Name}，返回FileInfo才是文件，DirectoryInfo就是目录 - 在 WSL2 子系统里检查时，注意路径是否经过
/mnt/c/映射 —— Windows 下的文件在 WSL2 里看到的仍是文件，但若通过 Docker Desktop 的 File Sharing 白名单挂载，路径解析逻辑可能绕过 WSL2 层，需以 Windows 原生视角验证 - 如果路径是符号链接，用
ls -la看真实指向，避免挂载了链接本身而非目标
挂载文件的正确写法与强制校验方式
挂单个文件，必须确保宿主机路径存在且是文件类型；Docker 本身不提供“只允许挂文件”开关，所以得靠前置动作兜底。
- 挂载前手动创建文件：
touch /host/config.yaml（Linux/macOS）或type nul > C:\config.yaml（Windows CMD），再运行容器 - 在 Compose 文件中，改用绝对路径并加注释说明意图，例如：
/absolute/path/on/host/config.yaml:/app/config.yaml # ensure this is a file, not dir - 临时加
--rm启动容器，进容器里执行ls -l /app/config.yaml，确认是文件且内容非空；若显示total 0或是空目录，立刻退出检查宿主机路径 - 避免用相对路径挂文件：如
./config.json:/app/config.json，因为./解析依赖当前 shell 工作目录，CI/CD 或不同终端下易错位
已经挂错怎么办：恢复原文件与防止复发
一旦发现容器内看到的是空目录，宿主机上的同名文件大概率已被覆盖或遮蔽。别急着删容器，先抢救：
- 立即停容器：
docker stop <container_id></container_id>，避免写入进一步污染 - 检查宿主机路径是否真被替换成目录：
ls -la /your/host/path；如果是，且你有备份或 Git 历史，赶紧恢复原文件 - 若没备份，且该路径原是重要配置，检查 Windows 回收站或启用的文件历史记录（File History）
- 长期预防：在 CI/CD 或本地启动脚本中加入校验步骤，例如：
[ -f "/host/config.yaml" ] || { echo "ERROR: config.yaml must be a file"; exit 1; }
最常被忽略的一点：Docker 不区分“挂文件”和“挂目录”的语法，全靠宿主机路径状态驱动行为。你以为写对了路径，其实系统里它早就是个同名目录了——这种隐式状态切换，才是这类问题难排查的根源。
