直接用前缀树索引大文件原始行内容不现实，因其会导致内存爆炸、构建缓慢、无法增量更新；高效做法是Trie仅存结构化关键词并挂载字节偏移量，通过file.Seek()定位原文件。
别直接用前缀树（Trie）索引大文件的原始行内容——它会吃光内存、构建慢、没法增量更新，且 Go 的 map[rune]*TrieNode 在深度分支多时 GC 压力明显。真实高效的做法是：Trie 只存关键词（如路径、ID、日志 tag），每个关键词挂一组字节偏移量，靠 file.Seek() 定位原文件位置。
为什么 Trie 直接存行内容在 Go 里不现实
10GB 日志文件逐行建 Trie，实际等效于把全部文本加载进内存再逐字符插入。实测中，10GB 原始数据可能撑出 30GB+ 的节点对象；scanner.Text() 返回的是新分配的 string，每行都触发堆分配；更麻烦的是，Go runtime 对高频小对象的 GC 回收并不友好，尤其当 Trie 深度超过 20 层后，GC STW 时间明显拉长。
真正该被 Trie 索引的，是每行提取出的**结构化关键词**，比如：
-
"api/v1/users"（HTTP 路径前缀） -
"ERROR"（日志级别） -
"user_12345"（业务 ID）
这些词本身数量有限、重复率高、长度可控，Trie 内存开销通常在 MB 级，构建也快。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
用 bufio.Scanner + offset 映射实现轻量 Trie 索引
核心是分离存储：Trie 管关键词，文件管原始内容。关键步骤如下：
- 用
bufio.Scanner流式读取，避免一次性加载整文件 - 对每行调用自定义提取函数（如
strings.SplitN(line, " ", 3)[2]或正则re.FindStringSubmatch）拿到关键词 - 在
scanner.Bytes()后、scanner.Scan()前，调file.Seek(0, io.SeekCurrent)获取当前字节偏移（注意：不能在scanner.Text()后取，指针已跳到下一行开头） - Trie 叶子节点存
[]int64，不是map[string][]int64—— 避免字符串 key 的哈希与拷贝开销 - 若关键词重复率极高（如日志中 80% 行都是
"INFO"），对 offset 列表做 delta 编码 +binary.PutUvarint压缩，可省 60%+ 存储
bleve 是本地全文检索唯一合理起点，但配置错一个地方就查不到
99% 的 Go 本地全文检索场景，不该手写倒排、不该硬套 Elasticsearch，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"，漏掉mapping.DefaultAnalyzer = "jieba"就切不开中文 -
Index()方法传的id必须稳定：别用filepath.Base(path)（多个 README.md 冲突），推荐用fmt.Sprintf("%x-%d", sha256.Sum256(content)[:8], fi.ModTime().Unix()) -
Index实例不是 goroutine 安全的，并发写入必 panic；批量用index.Batch()，单条用串行或sync.Mutex
小数据量别上引擎，中等规模优先 SQLite FTS5
几百个文件？直接 filepath.WalkDir + strings.Contains 就够了。几千个文本文件？SQLite FTS5 比 bleve 更省心：
- 建表一句：
CREATE VIRTUAL TABLE docs USING fts5(content) - 插入一句：
INSERT INTO docs(content) VALUES(?) - 搜索一句：
SELECT * FROM docs WHERE content MATCH 'keyword' - 不占额外进程、不需运维、响应稳定，且 FTS5 支持 phrase、prefix、near 等高级语法
- 千万别写成
WHERE content LIKE '%keyword%'——FTS5 不识别 LIKE，静默返回空
真正容易被忽略的，是文件预处理环节：编码归一化（如 GBK → UTF-8）、mimetype 过滤（跳过 PDF/ELF）、路径排除（.git、node_modules）、以及 HTML/Markdown 提纯（用 blackfriday 或 html2text 去标签后再索引）。这些不做，搜出来的结果根本不可信。
