判断路径是否为挂载点必须比较其与父目录的st_dev值是否不同，而非依赖os.stat(path).isdir()或存在性检查；该方法在linux/macos上稳定有效，但根目录mounted("/")恒返回false，父目录不可访问时需区分错误类型，符号链接需用os.lstat避免自动解析。
如何判断一个路径是不是挂载点
不能靠os.Stat(path).IsDir()或检查是否存在，必须比对设备 ID。Linux/macOS 上唯一稳定的方法是：获取路径和其父目录的syscall.Stat_t.Stdev，若不等，则是挂载点。
-
filepath.Join("/", "..")仍返回"/"，所以Mounted("/")恒为false，这是正确行为 - 父目录不可访问（如 NFS 断连、权限不足）时，
os.Stat会返回os.ErrPermission或&os.PathError{Op: "stat"}，不能只判os.IsNotExist - 符号链接会被
os.Stat自动解析；若需检测挂载点本身（而非目标），应改用os.Lstat并手动处理路径逻辑
为什么 fstest.MapFS 不能用来测挂载逻辑
fstest.MapFS不是挂载点，它连内核 VFS 都不接触，只是静态键值对 map，用于验证代码能否消费fs.FS接口（比如http.FileServer或template.ParseFS）。
- 调用
fs.OpenFile(..., os.O_CREATE|os.O_WRONLY, ...)直接 panic："not implemented" - 误以为它能替代
bazil/fuse——两者抽象层级完全不同：MapFS在用户态内存里，FUSE要注册到内核 - 构造方式决定不可变性：
fstest.MapFS{"a.txt": &fstest.MapFile{Data: []byte("hi")}}只是初始化，不触发任何挂载行为
如何用 /proc/mounts 获取挂载选项（如 ro、noexec）
Go 标准库不暴露挂载选项，os.Stat和unix.Statfs都拿不到；findmnt输出格式不稳定，容器中还可能不可用。最可靠的是直接读/proc/mounts。
- 逐行读取，用
strings.Fields(line)分割，第 2 字段是挂载点路径，第 4 字段是 options（如"rw,noatime,errors=remount-ro"） - 匹配时注意路径已自动 resolve 符号链接，但 bind mount 不会展开层级；若需区分 overlayfs/tmpfs，需同时看第 3 字段（文件系统类型）
- 别用
exec.Command("findmnt", "-n", "-o", "options", path)——不同发行版输出空格数、是否带 color、字段名（relatimevsstrictatime）都不一致
挂载检测器容易忽略的边界情况
真实环境里，Mounted函数常被当成“有就行”，但以下三点不处理，测试就不可靠：
- 根目录
"/"必须单独处理，否则filepath.Join("/", "..")导致逻辑错乱 - 父目录
os.Stat失败时，不能直接 return false；得区分os.ErrPermission、syscall.ENOTCONN（NFS 断连）等场景，否则误判为“未挂载” - 某些 overlayfs 或 LVM thin pool 场景下，
st_dev可能相同但实际是独立挂载点——此时需 fallback 到解析/proc/self/mountinfo（字段更细，含 mount ID 和 parent ID）
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
