/proc/mounts 是最权威的挂载状态来源，由内核实时生成、无缓存、字段固定（设备、挂载点、类型、选项、dump、pass），比 mount 命令更底层，不省略也不替换别名，如 bind mount 源路径不展开、tmpfs 设备列为 tmpfs 而非 ?。
直接读 /proc/mounts 就是最权威的答案——它由内核实时生成，不经过用户态缓存，所有已生效挂载都一定在这里。
为什么 /proc/mounts 比 mount 命令更底层
mount 命令默认就是读取 /proc/mounts，但加了格式化和过滤逻辑；而 /proc/mounts 是原始内核视图，字段顺序固定（设备、挂载点、类型、选项、dump、pass），没有省略、没有别名替换。比如 bind mount 的源路径不会被展开，tmpfs 行的设备列是 tmpfs 而不是 ?。
常见误操作：
- 用
cat /etc/mtab当真实状态——它可能滞后或被 systemd 绕过，尤其在容器或 initrd 环境中不可靠 - 只信
df -h输出——它会跳过所有无块设备的挂载（proc、sysfs、securityfs等），导致你以为“没挂载” - 依赖
mount | grep xxx查某路径——正则容易误匹配（如查/data却命中/data-backup）
findmnt 怎么交叉验证 /proc/mounts 的结果
findmnt 底层也读 /proc/mounts，但它会同时比对 /etc/fstab 和 /run/mount，能标出哪些挂载来自 fstab、哪些是临时手动挂载、哪些是 automount 触发的。这对排查“为什么重启后挂载消失”特别有用。
实操建议：
- 查某路径是否真被挂载：用
findmnt /path，它会向上追溯最近的挂载点，比grep精准 - 确认挂载是否持久：加
-D参数，输出里带FSTAB标记的才是 fstab 驱动的 - 导出机器可解析字段：用
findmnt -n -o SOURCE,TARGET,FSTYPE,OPTIONS，避免空格和表头干扰脚本 - 过滤远程挂载：用
findmnt --types nfs,nfs4,cifs，mount本身不支持类型过滤
挂载点显示为 ? 或空 SOURCE 是不是出错了
不是错误，是内核明确告诉你“这个挂载没有对应块设备”。典型场景包括：
-
tmpfs、ramfs、devtmpfs：内存文件系统，/proc/mounts中设备列为tmpfs或? - bind mount：
mount --bind /a /b后，/proc/mounts第一列是原挂载点的设备（可能仍是?），不是/a的路径 - overlayfs、aufs 等分层文件系统：
SOURCE列为空，得看lowerdir/upperdir选项才能还原结构 - 刚卸载但条目残留：内核未立即清理，此时访问挂载点会报
No such file or directory，而非卡住
真正要警惕的是：某行 TARGET 存在但实际 ls /target 卡住或报 Stale file handle——这说明 NFS/CIFS 连接中断，但内核还没撤掉条目。
systemd automount 导致 /proc/mounts 不显示怎么办
如果 /etc/fstab 里某行写了 x-systemd.automount，那么该挂载点在首次访问前根本不会出现在 /proc/mounts 中。这不是 bug，是设计行为。
验证方式：
- 执行
ls /mnt/nfs-share，若卡顿几秒后列出内容，说明 automount 已触发，再跑cat /proc/mounts | grep nfs-share就有了 - 查 systemd 状态：
systemctl list-units --type=automount | grep nfs，再用systemctl status xxx.automount看是否 active - 强制预热挂载：
systemctl start xxx.mount（注意是.mount，不是.automount）
这类挂载不会写进 /proc/mounts 直到第一次访问，所以任何基于该文件的自动化检查（比如监控脚本）必须先 touch 一下目标路径，再读 /proc/mounts。
