Bind Mount 中 inotify 事件无法穿透是 Linux 内核设计限制，因容器内 inotify 实例无法接收宿主机文件系统发出的 IN_MODIFY 等信号；可行方案包括轮询检测、正确挂载下用 fsnotify 监听挂载点、或 hostPath 配合事件代理。
在 bind mount 中无法直接透传 inotify 事件——这不是配置错误，而是 linux 内核和 docker 的设计限制。宿主机对挂载文件的修改（如保存 config.yaml）确实会实时同步到容器内，但容器进程监听不到 inotify 事件，导致热重载逻辑不触发。
为什么 inotify 不穿透 Bind Mount
Linux 的 inotify 机制只监控“本命名空间内”的文件系统事件。Bind Mount 虽然让容器看到宿主机文件，但文件实际 inode 和监控上下文仍属于宿主机内核空间。容器内的 inotify 实例无法接收宿主机 fs 层发出的 IN_MODIFY 或 IN_CREATE 信号，就像隔着一层玻璃看人敲键盘——画面有、声音无。
绕过限制的三种可行方案
不依赖 inotify 穿透，而是换一种方式感知变更：
-
轮询检测（最简单可靠）：应用每隔 100–500ms 检查目标文件的 mtime 或 checksum。适用于开发环境，开销低、兼容性好。Go 可用
os.Stat().ModTime()，Node.js 可用fs.statSync().mtimeMs。 -
用 fsnotify 监听挂载点本身（需正确挂载）：确保挂载时未使用
:cached或:delegated（尤其在 macOS/WSL2 上）。Linux 主机上原生 Bind Mount 默认支持部分 inotify 事件；若仍失效，可在容器内用inotifywait -m /app/config.yaml手动验证是否可捕获事件。 -
改用 hostPath + 文件系统事件代理（进阶）：在宿主机起一个轻量 watcher（如用 inotify-tools 或 Python watchdog），一旦检测到变更，通过 HTTP、Unix socket 或 signal（如
kill -SIGHUP）通知容器内进程重载。这种方式解耦清晰，适合 CI/CD 或测试场景。
必须避开的坑
以下操作看似合理，实则无效或引入新问题：
- 在容器内执行
echo 1 > /proc/sys/fs/inotify/max_user_watches—— 容器 cgroup 通常无权限，且不解决穿透问题。 - 用
docker exec -it xxx touch /app/config.yaml触发重载 —— 这只是模拟修改，不能代表真实开发流程中的保存行为。 - 把整个项目目录设为
:ro只读挂载后又试图 reload —— 配置文件不可写，连轮询比对 mtime 都可能失败（取决于应用实现）。
针对 C# TestContainers 的特别提醒
在集成测试中验证“配置热更新”，不要依赖宿主机直接改文件并期望容器内 .NET 进程自动响应。推荐做法是：
- 用
Container.ExecCmd("sh", "-c", "echo 'new_value' > /app/appsettings.json")在容器内修改文件，再触发重载逻辑； - 或在测试代码中调用服务暴露的重载端点（如
POST /api/reload），由服务主动读取当前磁盘内容； - 避免 bind mount + inotify 组合用于断言热重载，它在多数 CI 环境（尤其是 Docker-in-Docker）下行为不稳定。
