go语言必须通过bazil/fuse调用内核fuse模块实现真实挂载，因os/fs或net/http无法响应内核vfs请求；挂载点须为空目录、进程常驻、权限正确，且所有handler需recover panic。
Go 语言本身不提供内核级挂载能力，所有自定义挂载逻辑必须依赖 bazil.org/fuse（或其活跃分支）与 Linux 内核 fuse 模块通信；os/fs、http.FileServer 或任何纯用户态抽象都无法让 /mnt/myfs 这类路径被内核识别为真实文件系统。
为什么不能绕过 fuse 直接“模拟挂载”
挂载点不是普通目录，而是内核 VFS 层的入口。当你执行 ls /mnt/myfs，内核会触发 readdir 系统调用，并通过 FUSE 通道把请求发给你的 Go 进程——这个过程无法被 net/http 拦截，也不能靠 os.ReadDir 响应。
-
os/fs.FS只能用于embed.FS、io/fs.WalkDir等纯内存/只读场景，不参与 VFS 调度 - 试图用
syscall.Mount绑定一个 Go 函数地址？内核根本不认识 Go 的函数指针 - 常见错误：把
http.ListenAndServe(":8080", http.FileServer(...))当成挂载——这只是起个 HTTP 服务，和mount -t fuse完全无关
bazil/fuse 中实现挂载的核心三步
挂载不是“启动一个服务”，而是注册 handler、建立 /dev/fuse 通道、并让内核把该路径的所有 inode 操作转发给你。关键步骤如下：
- 创建 root node：用
nodefs.NewNodeFS或pathfs.NewLoopbackFS构建文件系统抽象，它必须实现nodefs.Node接口（如GetAttr、Open） - 调用
nodefs.Mount：传入挂载点路径（必须为空目录）、root node 和可选配置（如debug、allow_other）；返回*nodefs.FileSystem和error - 保持进程常驻：必须调用
server.Serve()阻塞运行，否则挂载会立即断开；不能 deferserver.Unmount()后就退出 main
示例片段：
fs := pathfs.NewLoopbackFS("/tmp/src")
server, _, err := nodefs.Mount("/mnt/myfs", fs, nil, nil)
if err != nil {
log.Fatal(err) // 挂载失败通常因权限、空目录、fuse模块未加载
}
defer server.Unmount() // 注意：这行不能放在 server.Serve() 之前
server.Serve() // 必须阻塞在此
自定义行为必须覆盖的底层 handler
FUSE 协议暴露的是 POSIX 接口，不是 HTTP 路由。每个操作对应一个明确的 handler 方法，漏掉任一关键方法会导致命令报错（如 cp: cannot create regular file）：
-
GetAttr：决定ls -l显示的权限、大小、时间戳；不实现则默认返回ENOSYS -
Open+Read/Write：控制文件读写；Write返回字节数和fuse.OK才算成功写入 -
Mkdir/Rmdir/Unlink：影响mkdir、rm行为；若只读文件系统，这些应返回fuse.EROFS - 所有 handler 必须
recover()panic：FUSE 内核不接受 Go panic，未捕获会导致整个挂载崩溃并卡死umount
挂载点检测与调试的现实陷阱
你以为挂载成功了？不一定。Linux 下挂载状态不可信，必须交叉验证：
- 用
findmnt /mnt/myfs或mount | grep fuse查看是否真在内核挂载表中；df显示fuse.xxx类型才对 - 挂载点目录必须为空：即使有隐藏文件（如
.git），Mount也会静默失败（错误被吞掉），需提前ls -a /mnt/myfs - 调试时加
--fuse.debug=true参数，日志会输出每条 FUSE 请求的 opcode 和参数；但注意：日志量极大，别在生产环境开 - 权限问题最常见：非 root 用户挂载需
user_allow_other+/etc/fuse.conf开启，且挂载点属主得是当前用户
真正难的不是写 handler，而是让内核持续信任你的进程——它一旦 crash，umount -f 都可能 hang 住，因为内核还在等响应。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
