strings.Index + bufio.Scanner 已满足绝大多数文件检索需求；标准库自动适配算法，手写KMP/BM易因预处理、UTF-8误处理、边界panic等拖慢速度，且BM仅在特定场景下更优。
直接用 strings.Index + bufio.Scanner 就能应对绝大多数文件内容检索场景；真要压榨性能，得先确认瓶颈在匹配本身，而不是 I/O 或正则解析。
为什么别一上来就手写 KMP 或 BM
Go 标准库的 strings.Index 在文件搜索中基本够用——它不是固定算法，而是按输入自适应：模式串 ≤ 64 字节时走暴力匹配（无预处理、缓存友好），长模式+长文本时自动切分或启用类似 Rabin-Karp 的指纹扫描。你手动实现 KMP/BM 反而容易因预处理开销、内存分配、UTF-8 边界误处理拖慢整体速度。
-
strings.Index对空串会 panic，而你自己写的 KMP 若没加if len(pattern) == 0判断，运行时直接崩溃 - 在日志行匹配（如每行 100 字符、查 “ERROR”）这种典型场景下，
strings.Index比手写 KMP 快 2–5 倍，因为免去了fail数组构建和 slice 转换成本 - 含中文或 emoji 的文本里，若你把
string强转成[]rune再喂给 KMP，匹配逻辑就完全错位——KMP 是字节级算法，不是语义级
大文件逐行扫描时，bufio.Scanner 怎么配才不翻车
默认 Scanner 行缓冲上限是 64KB，遇到超长日志行（如 minified JSON）会直接报 scanner: token too long。这不是匹配问题，是读取阶段就失败了。
- 用
scanner.Buffer(make([]byte, 4096), 1 手动设大缓冲，第二个参数是最大令牌长度（例如 1MB） - 避免用
scanner.Text()后再做strings.Index——这会触发slicebytetostring分配；改用scanner.Bytes()+bytes.Index，跳过 UTF-8 解码，对 ASCII 关键词（如 HTTP 方法、状态码）快 2–3 倍 - 若只查单字符或固定双字节序列（如
\r\n），直接上bytes.IndexByte或bytes.Index配[]byte("\r\n")，省掉一次 string→[]byte 转换
多关键词、高并发搜索时，regexp 和 ahocorasick 怎么选
当你要同时匹配 “GET|POST|PUT|DELETE” 或敏感词列表（>10 个），循环调用 strings.Index 是最差方案——同一段内存被反复扫描，CPU cache 友好性极差。
立即学习“go语言免费学习笔记（深入）”；
- 简单正则（无捕获组、无回溯）如
"GET|POST|HEAD"，用regexp.MustCompile；Go 的regexp包在模式简单时会自动编译为 Aho-Corasick 类状态机，比循环快一个数量级 - 纯关键词集合（无正则语义）、模式数 > 50 且稳定不变，用
github.com/BobuSumisu/ahocorasick；它不依赖 CGO，支持 Unicode，Match返回的是字节偏移，需配合utf8.RuneCount换算字符位置 - 模式动态增删频繁（如每秒更新规则），别碰 AC 自动机——重建开销大；改用
map[string]struct{}做前缀哈希筛 +strings.HasPrefix二次确认，更实际
真正需要自己实现算法时，Boyer-Moore 比 KMP 更值得写
除非你在做教学演示或调试协议解析器，否则 KMP 几乎没有工程价值。BM 算法在真实文本中平均跳得更远，尤其英文、代码类内容，实测比 KMP 快 1.5–3 倍。
- 必须处理两个硬约束：
if len(pattern) == 0提前返回，以及坏字符表用[256]int数组（非map[byte]int）提速约 20%，但仅限 ASCII 子集 - 匹配循环里别直接用
text[i+j]——如果i+j超出len(text)，会 panic；得加边界检查或用 unsafe.Slice（不推荐除非你清楚后果） - BM 不处理好后缀规则时，退化为坏字符单规则，已足够应付多数文件检索；完整版实现复杂度陡增，且收益在小文本中不可见
最常被忽略的一点：性能瓶颈往往不在匹配算法本身，而在每次匹配都新建 []byte、反复触发 GC，或者用 s[i:j] 返回子串导致隐式分配。对外接口优先返回 int 偏移，让调用方决定是否提取内容。
