必须通过 bazil/fuse 与内核 /dev/fuse 通信实现挂载，mount() 需在主 goroutine 中阻塞运行；readdir 要按 offset 分页返回非空切片并终以 io.eof 结束；open/read 需避免内存加载、正确设 flags 并利用预分配 buffer。
不能用 os/fs 或 net/http 模拟挂载点，必须走 bazil/fuse（或 jacobsa/fuse）与内核 /dev/fuse 通信，否则挂载路径只是普通目录，ls、cat 等命令根本不会触发你的代码。
挂载后 ls /mnt/myfs 卡住或报 Transport endpoint is not connected
这是最常见也最致命的问题，本质是 FUSE 事件循环没真正跑起来。
-
Mount()调用必须在主 goroutine 中执行，且之后不能 return、不能 os.Exit、不能让 main 函数结束 —— 否则内核收不到响应，挂载点就“活埋”了 - 别写
defer fuse.Unmount()然后直接return；Unmount()是同步阻塞的，但挂载后程序已卡在server.Serve()，defer 根本不执行 - 正确做法：挂载成功后，用
select {}永久阻塞，或启动一个空http.Server做健康检查入口，但主 goroutine 必须存活 - 如果反复测试，先执行
fusermount -u /mnt/myfs；若报Device or resource busy，说明内核还在等你响应，此时 kill 掉残留进程再试
ReadDir 实现返回空切片导致 ls 卡死或 CPU 拉满
FUSE 协议对目录遍历有明确状态语义，不是“有就给，没就空”，而是靠 offset 和 io.EOF 驱动分页。
- 返回空切片
[]fuse.Dirent{}会被内核当作“暂时无数据”，立刻重试调用，形成无限循环 - 必须首次传入
offset == 0，每次返回一批项，并把最后一项的Inode记为下一次的起始offset - 读完所有项后，才返回
io.EOF；中间任何一次都得返回非空切片 - 每个
fuse.Dirent的Name不能含/，Type必须设对（fuse.DT_Dir、fuse.DT_File），且Inode字段不能为 0 —— 内核靠它做缓存和一致性校验
Open+Read 大文件时内存爆掉或返回空内容
默认实现容易把整个文件 load 进内存再返回，对 >2GB 文件直接 OOM；或者忘了设 Flags 导致 Read 根本不被调用。
-
Open方法里必须返回一个可读句柄（如*os.File、io.ReadCloser），并显式设置openRes.Flags = fuse.OpenReadOnly（写操作同理） -
Read的data []byte是内核预分配的缓冲区（通常 128KB），你只需copy(data, src)并返回实际字节数；返回 0 表示 EOF - 不要在
Read里做seek或close—— 资源释放逻辑必须放在Release方法中 - 如果底层是 HTTP 流或数据库游标，超时和重连必须封装在
Read内部，不能依赖Open初始化一次就完事
真正难的不是写几个 handler，而是理解 FUSE 是严格的状态机协议：每个系统调用对应唯一 opcode，每个响应必须带准确的 Unique 和 Inode，panic 不 recover 就会让整个挂载点不可恢复。别试图绕过 /dev/fuse，那条通路是唯一的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
