os.stat在海量小文件场景卡住，因其每次调用均触发完整vfs路径解析、dentry查找与inode加载，等价于statx()系统调用，需读取全部元数据字段；而df -i显示inode耗尽（98%）远快于磁盘空间（20%），印证元数据操作成为瓶颈。
小文件元数据性能瓶颈不在 Go 代码，而在文件系统 inode 和目录项查找——直接上 os.Stat 或遍历 filepath.WalkDir 查 100 万个路径，df -i 很快飙到 98%，但磁盘空间才用 20%。
为什么 os.Stat 在海量小文件场景下会卡住
每次 os.Stat 都触发完整 VFS 路径解析 + dentry 查找 + inode 加载，不是“查一下是否存在”那么简单。Linux 下它等价于 statx() 系统调用，要读取 atime/mtime/ctime/inode/size/block 数等全部字段。
- 常见错误现象：
pprof显示 CPU 热点在syscall.Syscall和runtime.futex；strace -e trace=statx看到上万次阻塞调用 - 仅判断存在性：改用
os.Lstat(path)（跳过符号链接解析）或更轻量的os.OpenFile(path, os.O_RDONLY|os.O_CLOEXEC)+ 检查errno == syscall.ENOENT - 批量判断：必须用
filepath.WalkDir一次遍历，而不是对每个路径单独os.Stat - 注意：
os.IsNotExist(err)只匹配syscall.ENOENT，NFS 或某些容器挂载可能返回syscall.EACCES，需额外判错
元数据不该存文件系统，而该进键值库
把 100 万个文件的路径、大小、哈希、上传时间存成 100 万个独立文件（如 meta/abc.jpg.json），等于把数据库当文件系统用——inode 消耗爆炸，目录项膨胀，readdir 变慢，备份困难。
- 推荐方案：用
BadgerDB或bbolt存元数据，key 用文件逻辑路径（如"group1/abc.jpg"），value 序列化为msgpack或自定义二进制结构（比 JSON 小 30%+） - 避免用
map[string]interface{}直接序列化，字段名重复存储浪费空间；定义固定 struct，用gob或protobuf编码 - 写入时开启 batch：BadgerDB 的
Txn.SetEntry+Txn.Commit批量提交，比单条快 5–10 倍；bbolt 用DB.Update包裹多条bucket.Put - 查询走 key prefix scan：比如查
"group1/"下所有文件，用Iterator.Seek("group1/")+Prefix过滤，不用全表扫
如果必须落盘，别用单文件单元数据
真没法引入外部依赖（比如嵌入式设备），又得本地存元数据，就别碰 os.Create("meta/xxx.json") 这种路子——每建一个文件就占一个 inode，且目录项线性增长。
- 合并存储：按天或按大小切片，写成
meta/20260613.meta，内部用定长记录（如 128 字节/条）或gob编码的 slice，避免解析开销 - 偏移索引：维护一个内存 map
map[string]int64记录每个文件名在 .meta 文件中的 byte offset，ReadAt直接跳转读取，不加载全量 - 原子写入：先写
20260613.meta.tmp，再os.Rename覆盖，防止断电损坏 - 滚动策略：单个 .meta 文件限制 64MB，超限自动切新文件，否则 mmap 映射慢、grep 查找卡死
真正难的不是怎么存，而是怎么让“查一条元数据”和“查一百万条”耗时基本一致——这靠的是跳过文件系统层抽象，用键值索引代替路径遍历。一旦开始 os.Stat 套 for 循环，就已经在往坑里跳了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
