答案是挂载方式与编辑行为不匹配：挂单文件绑定inode，编辑器替换文件导致inode变更，容器仍指向旧inode；挂目录则路径级绑定，可实时感知变更。
宿主机改了文件，容器里没反应——这不是 Docker 坏了，而是挂载机制和编辑行为“对不上号”。核心就两点：你挂的是 路径 还是 inode？你改文件时，是覆盖写还是替换新文件？搞清这两点，问题基本就解了一半。
优先挂载目录，别挂单个文件
挂目录（比如 -v /host/config:/app/config）是路径级绑定，容器能实时看到增删改。挂单个文件（比如 -v /host/app.conf:/app/app.conf）则绑定的是当时那个 inode，一旦编辑器替换文件、inode 变了，容器还盯着旧的 inode 看，自然不更新。
- 开发环境一律用目录挂载，哪怕只用一个配置文件，也把它放进单独的 config/ 目录里再挂
- 线上部署若必须挂单文件，建议用 volume + COPY 初始化，而非 bind mount
- 检查 docker-compose.yml，确认 volumes 段写的是目录路径，不是具体文件名
编辑文件时避免 inode 变更
vim、nano、gedit 等默认保存方式是“写临时文件 + rename 覆盖”，这会生成新 inode。要让容器持续看到变化，就得让编辑操作直接写原文件。
- vim 用户可在
~/.vimrc加两行：set backupcopy=yes和set noswapfile - 临时生效：打开文件后输入命令
:set backupcopy=yes - 脚本或批量修改时，用
echo "new content" > file或sed -i 's/old/new/' file，它们直接覆写，不换 inode - 用
ls -i filename对比修改前后，确认 inode 是否一致
跨设备挂载与缓存干扰
宿主机挂载路径（如 /mnt/data）和 Docker 工作目录（如 /var/lib/docker）若不在同一块物理盘上（比如 SSD + HDD），inotify 事件可能延迟甚至丢失，导致容器内感知滞后。
- 把挂载目录移到和 Docker daemon 同一磁盘分区下，例如都放在
/opt或/data - macOS 用户在 docker-compose.yml 中加
consistency: cached - Linux 用户（尤其 WSL2）可设
consistency: delegated，降低同步等待 - Docker Desktop 设置里检查 “Resources → File Sharing”，确保对应路径已勾选并重启后台服务
权限与只读设置别踩坑
有时容器“看不见”变化，其实是权限拦住了。比如宿主机文件权限为 644，而容器内进程以非 root 用户运行，就可能读不到最新内容；或者挂载时误加了 :ro，导致容器内无法响应变更。
- 启动容器前，用
chmod 644 文件名或chmod 755 目录名统一权限，避免 777（不安全且未必有效） - 检查挂载语句末尾有没有
:ro，有则删掉，或显式写成:rw - 容器内用
id和ls -l /mounted/path确认用户 UID/GID 与宿主机文件属主是否匹配 - 必要时加
--user $(id -u):$(id -g)让容器进程身份对齐宿主机
