直接用 strings.Contains 搜索大文本慢是因为暴力匹配时间复杂度为 O(n×m)，而 KMP 可优化至 O(n+m)；需预计算 next 数组并复用，避免重复构建，且小模式串应优先使用 bytes.Index 内置优化。
为什么直接用 strings.Contains 在大文本里搜关键词会慢？
因为它是暴力匹配，时间复杂度 O(n×m)，当文本几 MB、模式串几十字符时，单次搜索可能卡住几十毫秒。尤其在日志分析、协议解析等场景下，频繁调用会拖垮吞吐量。KMP 能把最坏情况压到 O(n+m)，但 Go 标准库没暴露 KMP 接口——你得自己实现，且不能只抄教科书伪代码。
KMP 的 next 数组必须预计算，且不能每次重算
很多人写 KMP 时把 next 计算塞进主搜索循环，结果模式串不变、文本变，却反复构建 next，性能反而更差。正确做法是：对固定模式串提前算好 next，封装成可复用结构体。
-
next数组长度等于模式串长度，next[i]表示pattern[0:i]的最长真前缀后缀长度 - Go 中建议用
[]int存储，避免 slice 扩容开销；若模式串极长（>10KB），可考虑用sync.Pool复用数组 - 注意边界：空串或单字符时
next[0]必须为 0，否则index指针越界
Go 实现要避开 unsafe 和 reflect，但可用 bytes.Index 做 fallback
纯 KMP 在小模式串上未必比标准库快——Go 的 bytes.Index 内部已针对短模式优化（如 SIMD 或 Boyer-Moore 变种）。工程中应分层处理：
- 模式串长度 bytes.Index，稳定且 CPU cache 友好
- 长度 ≥ 8 且重复使用：构造
KMPMatcher{pattern, next}，调用matcher.FindAllIndex() - 文本含大量 ASCII 但模式含 Unicode：KMP 仍适用，但需确保
pattern和text都是[]byte，避免 rune 转换开销
真实场景下的内存和 GC 压力比算法本身更关键
大文本检索常伴随流式处理（如读取文件或网络流），如果每次把整块文本 read 进内存再跑 KMP，GC 会频繁触发。实际应结合滑动窗口 + 部分匹配状态保存。
立即学习“go语言免费学习笔记（深入）”；
- 不要一次性加载 100MB 日志文件到
[]byte；改用bufio.Reader分块读，KMP 状态机需支持跨块续匹配（记录当前state和未匹配的尾部字节） - 避免在热路径上分配新 slice：比如
append结果索引时，预先按预估数量 make 容器 - 若需高并发检索，
next数组可全局复用，但state变量必须 per-request，别用闭包捕获共享变量
真正卡住性能的，往往不是 KMP 公式写错，而是没意识到 next 该缓存、文本该分块、结果该预分配。算法只是骨架，工程细节才是血肉。
