Bind Mount 本质是 Linux 内核 VFS 层的 mount --bind 机制，通过 MS_BIND 标志创建共享同一 inode/dentry 的路径别名，实现宿主机与容器间毫秒级文件操作透传，不复制数据、不新建文件系统。
Docker Bind Mount 的底层原理，本质是 Linux 内核 VFS（虚拟文件系统）层的绑定挂载机制，不是 Docker 自创的功能，而是复用 mount --bind 这一原生系统调用。学它，关键不在“记命令”，而在理解「路径映射如何被内核接管」和「容器视角下为何能实时同步」。
先抓核心一句话：Bind Mount 是让内核把对目标路径的所有文件操作请求，原样转发到源路径——不复制数据、不新建文件系统、不改变 inode，只改访问入口。
看懂 mount --bind 的内核行为
-
mount --bind /host/path /container/path实际触发的是mount()系统调用，传入MS_BIND标志 - 内核在 VFS 层为
/container/path创建一个新的vfsmount结构，其mnt_sb指向源路径所在文件系统的super_block，但mnt_root指向源目录的dentry - 从此，任何进程访问
/container/path/xxx，VFS 都会自动转译成访问/host/path/xxx对应的 inode 和 dentry - 所以读写、stat、open、unlink 全部透传，毫秒级同步，没有中间缓存或代理层
你可以用
cat /proc/self/mountinfo | grep bind查看当前所有 bind 类型挂载，字段4是 mount ID，7是父 mount ID，-后面的none bind就是标识。
理解 Docker 容器里为什么“看见”了宿主机目录
- Docker 启动容器时，会在新 mount namespace 中执行
mount --bind（或通过libcontainer调用syscall.Mount） - 这个 mount 只对当前 namespace 有效，不影响宿主机全局视图（除非用
sharedpropagation） - 容器 rootfs 的
/app目录，实际是 host 上/home/user/project的一个绑定视图，二者共享同一组 dentry/inode - 因此
ls /app和ls /home/user/project输出完全一致；echo hello > /app/a.txt在宿主机上立刻可见
注意：如果宿主机路径本身是另一个挂载点（比如 NFS 或 overlay2 下某层），bind mount 会继承它的 mount 属性（如
noexec,nosuid），除非显式覆盖。
动手验证底层逻辑的几个关键命令
-
查看挂载来源与传播类型：
findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS /app # 输出类似：/home/user/project /app none rw,bind 0 0
-
检查两个路径是否指向同一个 inode：
stat -c "%d %i" /home/user/project/config.yaml stat -c "%d %i" /app/config.yaml # 若设备号（%d）和 inode 号（%i）都相同，说明是同一文件实体
-
观察 mount namespace 隔离性：
# 在容器内执行 cat /proc/1/mountinfo | grep bind # 在宿主机上执行（PID 不同） cat /proc/<host-pid>/mountinfo | grep bind # 通常内容不同，证明 mount 是 namespace-local 的
别被“Docker 功能”带偏：重点始终是 Linux VFS
- Docker 的
-v /host:/container只是封装了mount --bind+ mount namespace 设置 + 权限检查 - 所有行为都受 Linux mount 语义约束：比如 bind mount 不能跨 chroot（除非 unshare），不能 bind 挂载不存在的源路径，目标路径必须已存在
- 常见误区如“Bind Mount 是 Docker 卷的一种”是错的——Volume 是 Docker 管理的独立目录，而 Bind Mount 是纯粹的内核路径别名
真正掌握它，就去读 man 8 mount 里 --bind 和 MS_BIND 的说明，再配合 strace docker run ... 抓系统调用，比背文档快得多。
