直接用 map[string][]int 建倒排索引，配合整数文档 ID 和双指针归并，可高效支撑几十万文件本地搜索；上亿级或需模糊/中文分词时应切至 bleve。
直接用 map[string][]int 建倒排索引，配合整数文档 ID 和双指针归并，就能撑住几十万文件的本地搜索；真要上亿级或支持模糊/中文分词，该切 bleve 就切，别硬扛。
为什么不用 MongoDB 或 SQLite 做文件索引
文件索引服务的核心诉求是「低延迟查路径」，不是「事务一致性」或「多客户端并发写」。用 MongoDB 会引入网络、序列化、连接池、权限校验等冗余开销；SQLite 虽然嵌入式，但每次 INSERT 都要 fsync，写入吞吐卡在磁盘 I/O 上，且无法天然支持文档 ID 有序归并。
- 建索引阶段：Go 进程内直接构建
map[string][]int，无跨进程通信，插入延迟稳定在纳秒级 - 查询阶段：关键词查表 + 双指针求交，全程内存操作，100 万文档 ID 列表交集可在
- 陷阱：有人把文件路径当 key 存进 map，结果内存暴涨、GC 频繁——必须用递增整数 ID（如
id := len(docs)），路径单独存docsByID := []string
如何保证倒排索引的文档 ID 严格递增且无重复
双指针归并依赖 value 切片（[]int）天然升序且无跳变。一旦插入乱序或含重复 ID，交集结果就漏匹配或死循环。
- 插入时不做排序：每次
append(idx[word], docID)前，先用sort.SearchInts(idx[word], docID)查重和定位插入点；若返回位置i满足i ，跳过 - 构建完成后统一去重+排序：对每个
idx[word]调用sort.Ints，再用uniq辅助函数原地去重（避免分配新 slice） - 关键约束：文档 ID 必须是连续整数（0,1,2…），不能是哈希值或文件名字符串——否则
sort.SearchInts失效，双指针逻辑崩溃
AND 查询必须用双指针，别用 map[int]bool
用户搜 "go index"，你要找同时含这两个词的文档。如果把 index["go"] 转成 map[int]bool，再遍历 index["index"] 查存在，内存翻倍且 CPU cache 不友好。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：两切片已排序，用双指针归并在
O(m+n)时间完成 - 示例逻辑：
func intersect(a, b []int) []int { i, j, out := 0, 0, make([]int, 0, min(len(a), len(b))) for i - 坑点：没提前判空，
a或b为空切片时直接 panic；必须加if len(a) == 0 || len(b) == 0 { return nil }
词归一化不只小写，标点和停用词必须过滤
搜 "Go!" 找不到 "go"，问题不在大小写，而在标点没剥离。更隐蔽的是中文场景：gse 分词后一堆单字“的”“了”，塞进索引只会拖慢查询、稀释权重。
- 英文预处理：用
strings.FieldsFunc(text, func(r rune) bool { return !unicode.IsLetter(r) && !unicode.IsNumber(r) })替代strings.Fields，干净切开"hello,world" - 中文过滤：调用
seg.RemoveStopWord(true)并加载自定义停用词表（默认表不含“goroutine”“channel”这类技术词） - 统一转小写：用
strings.EqualFold比strings.ToLower更准，且不分配新字符串（对café等 Unicode 字符安全） - 致命错误：把分词结果直接当 key 存，没做标准化——比如 “Go” 和 “go” 成了两个 key，查一个漏一个
最易被忽略的一点：索引构建完必须验证文档 ID 列表是否真的有序无重复，光靠“我写了 sort.Ints”不等于它生效了；建议在服务启动时跑一次 for _, ids := range idx { if !sort.IsSorted(sort.IntSlice(ids)) { log.Fatal("unsorted posting list") } }。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
