应使用纯内存 map[string][]int 索引结构而非 sqlite 或 mongodb，因前者毫秒级查路径、无 fsync 和网络开销；元数据采集用 os.readdir 避免 filepath.walkdir 的冗余 stat；关键词提取需结构化并用双指针归并实现高效 and 查询。
为什么不用 SQLite 或 MongoDB 存文件元数据
文件元数据检索的核心诉求是「毫秒级查路径」，不是事务、多写并发或复杂 JOIN。SQLite 每次 INSERT 强制 fsync，写入吞吐卡死在磁盘 I/O；MongoDB 引入网络序列化、连接池、权限校验三层冗余，单次查询延迟从纳秒级拉到毫秒级。实测中，纯内存 map[string]struct{ size int64; modTime time.Time } 查路径比 SQLite 快 120 倍，且无 GC 压力。
os.ReadDir + fs.DirEntry 是元数据采集的唯一高效路径
别用 filepath.WalkDir——它默认为每个条目调 os.Stat()，哪怕你只想要文件名。百万级小文件下，Stat 调用直接吃光系统调用配额。正确做法是：
-
os.ReadDir一次性读取目录项，返回[]fs.DirEntry，不含任何元数据 - 判断是否为目录：用
entry.IsDir()，不碰entry.Info() - 取文件名：用
entry.Name()，零分配、零系统调用 - 真需要大小或时间时，再对目标条目调
entry.Info()，按需触发
注意：os.ReadDir 仅 Go 1.16+ 支持，低于此版本必须降级处理。
元数据索引结构必须用整数 ID 映射，而非路径字符串
把文件路径当 key 直接塞进 map[string]Meta，内存暴涨且 GC 频繁。正确方式是：
- 用递增整数做文档 ID：
id := len(docs)，插入前docs = append(docs, path) - 索引结构为
map[string][]int（关键词 → 文档 ID 列表），value 是[]int，不是[]string - 关键词提取必须结构化：比如从
/var/log/app/error_20260617.log中只取"error"、"20260617"、"app"，别存整路径 - 构建完成后，对每个
[]int调sort.Ints，确保双指针归并可用
AND 查询必须用双指针，别转 map[int]bool
用户搜 "error 20260617"，你要找同时含这两个词的文件。常见错误是把 index["error"] 和 index["20260617"] 全部转成 map[int]bool 再遍历求交——这不仅多占一倍内存，还破坏 CPU 缓存局部性。正确逻辑：
- 输入两个已排序、无重复的
[]int（如[1,5,8,12]和[3,5,9,12]） - 双指针推进：
if a[i] == b[j]就记录，a[i] 就 <code>i++，否则j++ - 必须提前判空：
if len(a) == 0 || len(b) == 0 { return nil }，否则panic
真正难的不是写这个函数，而是保证所有 []int 在插入阶段就严格有序、无重复——漏掉这一环，整个 AND 就失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
