文件修改后容器内未立即更新，主因是宿主机page cache延迟或inotify事件未触发；需通过stat比对mtime/ctime、sync刷盘、inotifywait监听及md5sum校验字节一致性来精准定位。
文件修改后容器内没立刻更新，不一定是 docker 的问题，很可能是宿主机内核 page cache 或 inotify 事件未及时触发所致。排查重点不在容器，而在 linux 文件系统行为与挂载路径的 i/o 路径一致性。
确认是否为 page cache 延迟
Linux 默认启用写缓存：用户态修改文件后，数据先写入内存页缓存（page cache），再由内核异步刷盘。容器内进程读取时若走缓存路径，可能看到旧内容。
- 用 stat 查看宿主机和容器内同一文件的 mtime 和 ctime 是否一致；不一致说明容器内读到的是缓存副本
- 执行 sync 命令强制刷盘，再进容器检查——若此时同步了，基本可判定是 page cache 滞后
- 临时禁用缓存验证（仅测试）：echo 3 > /proc/sys/vm/drop_caches，但注意这会清空所有页缓存，影响系统性能
检查 inotify 事件是否送达容器
很多应用（如 nodemon、supervisord、配置热加载模块）依赖 inotify 监听文件变化。若事件未触发，应用就不会重新加载。
- 在容器内运行 inotifywait -m -e modify,attrib,move_self /mounted/path/file，同时在宿主机改文件，看是否有输出
- 若无响应，检查宿主机 inotify 限制：cat /proc/sys/fs/inotify/max_user_watches，过低（如默认 8192）会导致监听失效，可临时提高：echo 524288 > /proc/sys/fs/inotify/max_user_watches
- 确保挂载路径不在 NFS、overlayfs 等不完全支持 inotify 的文件系统上（尤其是 macOS/Windows Docker Desktop 的共享文件夹）
验证挂载路径是否跨物理设备
当宿主机挂载点（如 /mnt/data）和 Docker daemon 数据目录（如 /var/lib/docker）位于不同磁盘（SSD + HDD、或不同 NVMe 控制器），I/O 调度和 page cache 管理可能割裂，导致事件传播延迟甚至丢失。
- 用 df -T /mnt/data /var/lib/docker 查看两个路径的文件系统类型和设备名
- 用 lsblk 确认是否挂载在同一块物理盘（例如都是 sda1）
- 实测表明：把挂载目录移到与 /var/lib/docker 同一设备上，多数“等几秒才生效”现象消失
绕过缓存干扰的快速验证法
不依赖系统缓存机制，直接比对原始字节内容，能快速定位是缓存、inode 还是权限问题。
- 宿主机执行：md5sum /host/path/file
- 容器内执行：docker exec -it container_name md5sum /container/path/file
- 若 md5 不同，且 stat 显示 inode 相同 → 是 page cache 或应用未重读文件
- 若 inode 不同 → 是编辑器替换文件导致（如 vim），不是缓存问题，应改用目录挂载或 sed -i 类原地修改方式
