大文件搜索应流式逐行处理，用 bufio.scanner 配合 os.open，扩容缓冲区并检查 scanner.err()；行号用 bytes.count 累加；关键词匹配优先 strings.contains；中文分词用 go-ego/gse 并过滤停用词；索引推荐 bleve，需显式设分词器、绝对路径及及时 close。
大文件搜索别直接读全量
对几十 MB 以上的日志或文本文件，io.ReadAll 或 os.ReadFile 会触发 OOM，进程被系统 kill 是常态。真正能落地的做法是流式逐行处理。
- 用
bufio.Scanner配合os.Open打开文件，每行只占用缓冲区内存 - 默认单行上限是 64KB，遇到超长日志行会报
scanner: token too long；需提前调scanner.Buffer(make([]byte, 1024*1024), 1024*1024)扩容 - 记得在循环后检查
scanner.Err()，IO 错误（如权限不足、磁盘损坏）不会自动 panic，只会静默失败 - 若需行号，别依赖
strings.Count(line, "\n")—— Windows 换行是\r\n，正确做法是用bytes.Count(scanner.Bytes(), []byte("\n"))累加
关键词匹配优先用 strings.Contains
90% 的轻量搜索场景不需要正则，strings.Contains 比 regexp.MatchString 快 5–10 倍，且无编译开销、无回溯风险。
- 大小写敏感搜索：直接
strings.Contains(line, keyword) - 忽略大小写：统一转小写再比，
strings.Contains(strings.ToLower(line), strings.ToLower(keyword))；中文和 UTF-8 安全，无需额外处理 - 别在循环里反复调
strings.ReplaceAll或strings.Trim做清洗——如果只是查“error”，先 trim 再 contains 反而慢；真正要清洗，应在构建索引阶段做，不是运行时 - 高亮显示需求？先拿到匹配位置
strings.Index(line, keyword)，再拼 HTML 或 ANSI 转义，别用正则FindAllStringIndex多余开销
中文分词不能靠 strings.Fields
用 strings.Fields 或正则切中文，实际是按字切分，“搜索引擎”变成 ["搜", "索", "引", "擎"]，语义全毁。必须上专用分词器，且配置不对等于没用。
- 推荐
github.com/go-ego/gse，初始化时传seg.WithFrequency(false)关词频，省 30%+ 内存 - 分词后立刻过滤：长度 ≤1 的 token（如“的”、“了”）和停用词表里的项，否则索引膨胀、查询噪音大
- 别用
gse.NewGse("")默认词典——它加载全部词库，启动慢、内存高；生产环境应指定精简词典路径，如gse.NewGse("dict/dict.txt") - 英文混排场景（如 “HTTPHandler”），需搭配
en-icu分词器或自定义 tokenizer，否则可能把驼峰名错切成 “HTTP Handler”
bleve 不是重，是封死了最常崩的点
手写倒排索引教科书上看着简单，但一加真实数据就漏结果、卡死、查不到——bleve 不是“多一层依赖”，而是把字段映射、中文分词、落盘保证这些坑全踩过并封住。
-
bleve.New()前必须os.MkdirAll("/abs/path/to/index", 0755)；相对路径"./index"在 CI 或不同工作目录下必挂 - 中文字段必须显式绑定分词器：
mapping.AddFieldMapping("Content", "text").Analyzer("jieba")，光设Index(true)没用 - 字段名大小写敏感：
json:"content"和Content是两个字段；查询时写content:go就查不到Content字段 -
Index.Index()后不调Index.Close()，scorch 存储的数据可能未落盘，重启即丢——这不是 bug，是设计契约
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
