根本原因是编辑器保存时通过临时文件+rename()替换原文件，导致inode变更，而Docker单文件挂载绑定的是原始inode而非路径，容器内进程仍持有旧inode的文件描述符，故读不到新内容。
直接挂载单个文件（比如 -v /host/app.conf:/app/app.conf）时，宿主机上用 vim、nano 或 VS Code 保存后容器内看不到变化，不是 Docker Desktop 的 bug，而是文件系统层的 inode 替换行为导致的“假失效”。
为什么改了宿主文件，容器里还是旧内容？
根本原因在编辑器保存机制：大多数编辑器（vim 默认、nano、GUI 编辑器）不直接覆写原文件，而是创建临时文件 + rename() 原子替换。这个操作会让文件的 inode 编号彻底改变。
Docker 的 bind mount 在挂载单个文件时，绑定的是当时的 inode，不是路径。容器内进程（如 cat、nginx -t）仍打开着旧 inode 的 fd，自然读不到新内容——它没“卡”，只是没重新 open()。
验证方式：
- 宿主机执行 stat /host/app.conf 记下 inode
- 编辑保存后再次 stat，inode 已变
- 进容器执行 stat /app/app.conf，inode 仍是旧值
Mac 上用 Docker Desktop 挂载单个文件，有哪些坑？
macOS 的文件系统（APFS）+ Docker Desktop 的虚拟机（VMM）+ gRPC-FUSE 文件共享层，会叠加三层缓存和事件通知延迟。即使你绕过 inode 问题（比如用 echo > file），inotify 事件也可能丢失或延迟数秒，导致热重载类应用（如 Webpack、uvicorn）监听不到变更。
这不是配置错误，是设计限制：
- --mount type=bind,consistency=cached 是 macOS 的默认行为，牺牲一致性换性能
- 无法通过调高 inotify 限值或刷新 page cache 彻底解决
- 单文件挂载在 macOS 上本就不适合开发态热更新
怎么让修改真正同步到容器？
✅ 最可靠做法：别挂单个文件，改挂目录
- 把 -v /host/app.conf:/app/app.conf 改成 -v /host/config:/app/config
- 应用从 /app/config/app.conf 读取，目录级挂载天然支持增删改实时可见
✅ 临时救急（仅限调试）：
- 编辑时禁用备份/swap：在 vim 中加 set nowritebackup noswapfile，或启动时加 -n 参数
- 直接覆写不触发 rename：sed -i 's/old/new/' /host/app.conf 或 printf "new content" > /host/app.conf
- 容器内手动 reload（如 nginx -s reload）或 kill -HUP 对应进程，强制 reopen 文件
⚠️ 注意：docker exec -it container bash 进去改容器内文件，不会反向同步到宿主机——挂载是单向路径映射，不是双向同步工具。
哪些情况必须重建容器？
当容器内进程已长期持有旧 inode 的文件句柄（比如 nginx master 进程 fork 出 worker 后一直运行），且你不控制其 reload 逻辑时，仅靠改宿主文件无法生效。此时：
- docker restart 会重建整个 mount namespace，重新解析路径并绑定新 inode
- docker kill -s HUP 是否有效，取决于应用是否实现信号重载且 reopen 配置文件
- 如果应用本身不 reload（比如静态二进制服务），或你不确定其行为，重启是最稳妥的
真正容易被忽略的是：**挂载点权限和用户 UID/GID 匹配问题**。比如宿主机文件属主是 1001:1001，但容器内进程以 root 运行，某些场景下内核会静默 fallback 到只读视图——这种情况下连 inode 都不一致，stat 看到的可能是不同设备上的副本。
