真正可落地的索引只存元信息：关键词或锚点作key，struct{ offset int64; length int }作value；错误做法是将整行或块内容直接塞入跳表、Trie或map，导致内存暴涨与GC卡顿。
别把整行内容塞进跳表或 Trie
直接用 map[string]string 存日志行、用 map[string][]byte 存块内容，等于把文件镜像加载进内存——10GB 文件轻松吃掉 30GB 堆空间，GC 频繁卡顿，索引一写就过期。真正可落地的索引，只存元信息：关键词或锚点作 key，struct{ offset int64; length int } 作 value。
常见错误现象：
- 查得到前缀但返回空结果，90% 是因为存入时用了
scanner.Text()，查询却用strings.ToLower()，大小写不统一 - 构建时用原始行字符串插入，但没做
strings.TrimSpace()，导致末尾带\uFEFF或\r，key 实际不匹配 -
file.Seek(0, io.SeekCurrent)调在scanner.Text()后——此时指针已在下一行开头，所有偏移错位一行
正确时机是在 scanner.Bytes() 返回后、调 scanner.Scan() 前手动记录位置。
倒排索引必须满足三个刚性约束
map[string][]int 是起点，但不是全部。只要漏掉任意一条，AND 查询就漏结果、TF 计算错、内存涨得快。
立即学习“go语言免费学习笔记（深入）”；
- 文档 ID 必须是连续整数（0,1,2…），不能是路径哈希或 UUID——双指针归并依赖严格递增且无跳变
- 同一文档中重复出现的词，必须保留多次 ID（如 “error” 出现 5 次，就要 append 5 次 123）——高亮和权重计算都靠它
- 每个
[]int必须显式排序且去重（或插入时用sort.SearchInts查重再插）——否则双指针逻辑失效，退化成嵌套遍历
中文分词必须用 github.com/go-ego/gse，且必须传 seg.WithFrequency(false)；停用词过滤不能放循环里反复 make([]string, 0)，要预分配容量。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
suffixarray 只适合静态大文本高频复用
index/suffixarray 不是万能加速器，误用反而更慢。典型错误是每次用户输新关键词，都调一次 suffixarray.New(data)——构建耗时 20μs 起，比 strings.Index 的 30ns 慢 700 倍。
适用场景极窄：
- 文本稳定不变（如协议定义、日志模板）
- 长度 >10KB
- 后续查找 ≥200 次
其余情况，直接用 strings.Index 更快更省心。真要建索引，优先选 os.Seek + io.ReadAt 跳转，而不是把全文塞进内存结构。
bleve 是本地全文检索唯一合理起点
手写倒排索引适合 CLI 工具或教学验证，但一旦要支持中文分词、字段权重、模糊查询、增量更新，几乎必然掉坑。bleve 封死了最常崩的点，但配置错一个地方就查不到。
-
bleve.New()前必须os.MkdirAll("/path/to/index", 0755)，相对路径（如"./index"）在 CI 或不同工作目录下必挂 - 字段必须显式设
field.Index(true).Store(true)，仅靠json:"title"标签无效 - 中文字段必须绑定分词器：
mapping.AddCustomAnalyzer("jieba", analyzer)+titleField.Analyzer = "jieba" - ID 必须稳定合法，推荐用
sha256.Sum256哈希前 8 字节 + 修改时间戳拼接，绝不用filepath.Base
真正难的不是建索引，而是判断“这行值不值得索引”——比如日志里带毫秒时间戳的行，你索引的是原始字符串，还是 time.Time.UnixMilli()？后者才能高效范围查询。
