用os.stat比较路径与其父目录的st_dev是否不同来判断挂载点，该方法在linux/macos上可靠，windows不适用；根目录“/”因父目录即自身，mounted("/")恒返回false。
如何用 os.Stat 比较 st_dev 判断挂载点
Go 本身不提供直接列出所有挂载点的跨平台 API，但检测「某个路径是否为挂载点」是可行且稳定的，核心就是比较路径与其父目录的 st_dev 值是否不同。
这个方法在 Docker、runc 等生产级项目中被长期验证，原理简单但依赖底层 stat 行为，因此只适用于类 Unix 系统（Linux/macOS），Windows 不适用。
-
os.Stat返回的os.FileInfo底层包含syscall.Stat_t，其中Stdev字段即设备 ID - 对根目录
"/"调用filepath.Join("/", "..")仍得"/"，所以Mounted("/")必然返回false—— 这符合语义：根不是“被挂载到别处”的点 - 若父目录不可访问（如权限不足、NFS 挂载异常），
os.Stat会返回错误，不能仅靠os.IsNotExist判断；需区分os.ErrPermission或&os.PathError{Op: "stat"} - 符号链接会被自动解析，即
os.Stat跟随链接目标；如需绕过链接检查挂载点本身，应改用os.Lstat并手动处理路径逻辑
获取全部挂载点列表：必须调用系统命令或 syscall
想列出当前系统所有挂载点（类似 mount 或 findmnt 输出），Go 标准库无内置支持，只能走两条路：调用外部命令，或使用 golang.org/x/sys/unix 直接读取 /proc/mounts（Linux）或 getfsstat（macOS）。
- Linux 上最轻量的是读取
/proc/mounts：它是一份纯文本文件，每行格式为device mountpoint fstype options dump pass，可用os.ReadFile+strings.Fields解析 - macOS 需用
unix.Getfsstat，传入nil获取总数，再分配切片重试；返回的unix.Statfs_t包含挂载路径、类型等，但字段名与 Linux 不一致 - 避免用
exec.Command("mount")：输出格式受 locale 和版本影响（如某些发行版加 color、换行符不一致），解析脆弱 - 注意
/proc/mounts可能包含重复条目（如 bind mount），需根据mountpoint字段去重，而非设备名
syncfs 和挂载点状态强相关但不能替代检测
syncfs 是 Linux 3.2+ 引入的系统调用，作用是同步整个文件系统（而非单个文件），但它要求传入一个指向该文件系统内任意路径的**有效文件描述符**。这意味着你必须先确认路径属于哪个挂载点，才能安全调用它。
- 常见误用：对一个不确定是否为挂载点的路径，先
os.Open再unix.Syncfs—— 若该路径跨多个挂载点（如 bind mount 或 overlayfs），syncfs只同步其所在底层文件系统，不是“从该路径向上同步所有嵌套挂载” - 获取 fd 的方式必须是
os.Open或unix.Openat，不能用os.Create后 close 再传 fd —— fd 一旦关闭就失效 - 调用失败时 errno 可能是
EINVAL（fd 不指向挂载点根目录内的路径）或EPERM（无 CAP_SYS_ADMIN 权限），不是所有用户都能用
跨平台兼容性陷阱：别假设 st_dev 在所有系统都可靠
虽然 st_dev 检测法在 Linux/macOS 上稳定，但在某些场景下会失效，且 Windows 完全不适用。
- ZFS/Btrfs 的子卷（subvolume）或快照（snapshot）在挂载后，其
st_dev可能与父目录相同 —— 因为它们共享同一设备，但逻辑上是独立挂载点；此时需结合/proc/self/mountinfo中的major:minor和root字段做二次判断 - FUSE 挂载（如 adbfs、gocryptfs）通常伪造
st_dev，使其与父目录一致，导致检测失败；这类场景必须依赖/proc/mounts或 FUSE 自身的控制接口 - Windows 没有
st_dev概念，os.Stat返回的FileInfo.Sys()是*syscall.Win32FileAttributeData，不含设备标识；跨平台代码需用构建标签（//go:build !windows）隔离逻辑
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
