科技 · 实用指南
Docker 挂载后文件“消失”？先证明究竟哪个文件系统遮住了它们
先渲染 Compose 模型、检查实时挂载图并对比同一镜像的无挂载基线，再重建、复制或删除数据。
目录在容器启动后变空，通常不能证明镜像丢了文件。当前可见目录可能来自 bind、命名卷或嵌套挂载；Compose 也可能把相对源路径解析到了意外位置。
先保全数据，渲染实际模型，检查实时挂载图，再用精确镜像做无挂载对照。只有识别机制后才修复，并跨重建验收。
1. 冻结模型与数据证据
复制 Compose 文件、环境输入、工作目录、Docker context 和精确镜像摘要。只读列出主机目录或卷，记录属主、权限与代表性哈希，暂不复制或删除。
运行 docker compose config，保存渲染后的 volumes，并记录每个 source、target 与父子 target 冲突。
2. 读取实时挂载图
用 docker inspect 读取 Mounts 中的 Type、Source、Destination、RW 与 propagation，识别 bind、命名卷及嵌套目标。
bind 指向 daemon 主机。还要区分 -v 自动建目录与 --mount 对缺失源路径报错的行为。
3. 对比同一镜像的无挂载基线
用完全相同的镜像摘要创建无可疑挂载的临时容器并查看目标路径。文件重现说明镜像正常，是挂载在遮蔽。
再比较真实 bind 源或卷的文件名、哈希、属主和权限；对子挂载目标也做同样检查。
4. 分类后再修复
bind 只覆盖视图，不会把镜像文件合并到主机目录。全新空卷通常只复制一次；复用卷保持自身生命周期，volume-nocopy 可关闭初始复制。
若渲染模型或 inspect 显示意外 Source，应修正基础目录或项目路径，而不是重新灌入数据。
5. 有意修复并证明持久性
把持久数据挂载到应用安装树之外的专用目录。需要初始化时使用可重复、带版本和冲突规则的迁移，绝不盲拷贝覆盖数据库或用户卷。
用正确挂载重建，并验收首次启动、第二次重启或重建、读写、代表哈希、属主、预期存储持久性以及错误主机路径没有新写入。
