fsnotify 不支持挂载事件监听，因其仅封装各平台文件变更机制（如inotify/kqueue），而挂载属VFS层事件；Linux需轮询/proc/self/mountinfo或用netlink（5.15+），跨平台无统一方案。
fsnotify 不支持挂载事件监听
fsnotify 无法监听 mount / umount 事件。它只封装了各平台的文件变更通知机制（Linux inotify、macOS kqueue、Windows ReadDirectoryChangesW），这些机制本身就不上报挂载点增减——挂载属于 VFS 层事件，不在 fsnotify 覆盖范围内。
Linux 下可用 syscall.InotifyInit + IN_MASK_ADD + IN_MOVED_TO？不，IN_MOUNT 不可用
Linux inotify 确实定义了 IN_MOUNT 和 IN_UNMOUNT 事件常量，但它们**从不被内核触发**，仅作预留。实际测试和 kernel 文档均确认：inotify 对挂载事件完全静默。试图用 syscall.InotifyAddWatch(fd, "/path", syscall.IN_MOUNT) 不会报错，但永远收不到事件。
Linux 替代方案：netlink + NETLINK_ROUTE 监听 mount namespace 变更
真正可行的底层方式是监听 NETLINK_ROUTE socket 上的 RTM_NEWNSID / RTM_DELNSID（需 5.15+）或轮询 /proc/self/mountinfo 差分。但注意：
- Go 标准库无 netlink 封装，需用
golang.org/x/sys/unix手动构造 socket 和消息解析 -
/proc/self/mountinfo是最简单路径：启动 goroutine 每 500ms 读取并对比前次内容，os.Stat()验证挂载点是否存在即可捕获变化 - 挂载事件本身无“谁挂的”上下文，仅能感知到 mount table 变化；如需进程级溯源，必须搭配
fanotify（但 fanotify 也不直接暴露挂载动作）
跨平台统一方案不存在，macOS/Windows 无等价机制
macOS 没有公开的挂载事件通知接口，launchd 的 StartOnMount 是声明式启动策略，不可用于运行时监听。Windows 的 FindFirstVolume / FindNextVolume 是轮询 API，且只对 volume（卷）有效，对 bind mount 或 WSL2 挂载点无效。结论很直接：
立即学习“go语言免费学习笔记（深入）”；
- 不要尝试用 fsnotify 做挂载监听 —— 它设计上就不支持
- Linux 单平台需求可选
/proc/mounts或/proc/self/mountinfo轮询（低开销、稳定、无需 root） - 若必须实时且避免轮询，只能深入 netlink，但要承担协议解析复杂度和内核版本兼容风险
挂载事件监听不是“配置没对”，而是根本不在 fsnotify 的抽象边界内。别在 Add() 或 Events channel 里找答案，先确认你是否真的需要它——多数热加载场景其实只需监听已挂载路径下的文件变更。
