strings.index + bufio.scanner 已足够高效，标准库会按模式长度自动优化算法；需防空pattern panic、utf-8/gbk编码问题及scanner缓冲区溢出。
用 strings.Index + bufio.Scanner 做基础关键词匹配就足够了
别一上来就写 KMP 或 BM，标准库的 strings.Index 在绝大多数文件内容分类场景下更快、更稳。它不是固定算法，而是按模式长度自动切换：≤ 64 字节走暴力匹配（无预处理、缓存友好），长模式+长文本时会切分或启用类似 Rabin-Karp 的指纹扫描。
常见错误是把 strings.Index 当成纯暴力，然后自己重写 KMP——结果反而因 fail 数组构建、[]rune 强转（破坏 UTF-8 字节偏移）、边界 panic（比如空 pattern）拖慢整体速度。
-
strings.Index对空串会 panic，必须提前检查len(pattern) == 0 - 中文/emoji 场景下，KMP 若按
[]rune处理，匹配位置完全错位；strings.Index是字节级，天然兼容 UTF-8 - 日志行匹配（如查
"ERROR"）这种典型场景，strings.Index比手写 KMP 快 2–5 倍
超长行、GBK 编码、多关键词这些坑必须提前填
bufio.Scanner 默认行缓冲上限是 64KB，遇到 minified JSON 这类超长行直接报 scanner: token too long——这不是匹配失败，是读取阶段就崩了。
带 GBK 编码的日志文件，不转 UTF-8 就直接 Scanner，读出来全是乱码，后续匹配全失效。
- 调大缓冲：
scanner.Buffer(make([]byte, 1（第二个参数是最大令牌长度，设为 1MB） - GBK 文件先用
golang.org/x/text/encoding/gbk解码再交给 Scanner - 多个关键词（如
"GET|POST|PUT"）别循环调strings.Index，同一段内存反复扫描，CPU cache 友好性极差 - 简单正则（无捕获组、无回溯）用
regexp.MustCompile，Go 会自动编译为 Aho-Corasick 类状态机，比循环快一个数量级
分类规则要可配、可兜底、能加权
初期完全不需要模型或 TF-IDF，关键词规则（rule-based）更可控、易调试、上线快。重点是结构设计：每个分类标签关联一组关键词（含同义词、缩写），支持子串或正则，且必须有兜底机制。
容易忽略的是匹配逻辑细节：大小写是否敏感、是否允许跨词匹配、命中后是否立即终止还是累计权重。
- 关键词配置建议用 YAML/JSON 外置，支持热加载（监听文件变更）
- 匹配时不推荐
strings.ToLower全转小写——性能差且破坏原始格式；改用正则前缀(?i)，如(?i)error - 按命中次数或关键词权重打分，取最高分标签；全部未命中必须归入
"Other"，避免漏分类 - 标题和正文分开匹配，正文匹配可降权（如标题命中 ×1.5，正文命中 ×1.0）
并发搜索与错误收敛必须显式控制
处理多个文件时，裸起 go func() {}() 极其危险：panic 会崩掉整个程序，错误无法收集，文件句柄可能被系统 kill。
真正安全的做法是组合 sync.WaitGroup 和 errgroup.Group，并限制最大并发数（如 10）。
- 每个文件一个 goroutine，但通过
eg.Go(func() error { ... })统一管理生命周期 - 设置
eg.SetLimit(10)控制并发上限，防止打开过多文件句柄 - 所有错误统一收集，最后返回汇总错误列表，而不是只报第一个
- 每条匹配结果应携带文件路径、行号、匹配关键词，方便下游定位和审计
分类逻辑本身不复杂，但编码兼容性（XML/HTML 实体解码）、空内容兜底、并发限速、规则热加载这些点，漏掉一个就可能导致线上行为不可控。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
