strings.Index 是绝大多数场景的最优解，Go 1.19+ 已内置优化版 KMP 或 Rabin-Karp；仅当需复用模式串、重叠匹配或流式增量匹配时才手写 KMP。
别手写 KMP，除非你明确需要它带来的“可控性”——strings.Index 在绝大多数场景下就是最优解，且已内置优化版 KMP 或 Rabin-Karp。
什么时候该用 strings.Index 而不是自己实现？
日常子串查找、配置解析、日志关键词提取这类任务，直接调用 strings.Index 即可。它不是朴素匹配，Go 1.19+ 标准库对中长模式串（通常 >8 字节）自动切到 Rabin-Karp，短串则走字节级 memchr 优化；你手动重写几乎不可能更快，反而容易引入 bug。
-
strings.Index要求substr非空，传空串会 panic；你自己写的 KMP 若没加len(pattern) == 0判断，运行时可能崩溃 - 高频调用下，标准库复用内部缓冲、避免重复分配；而手写版本若每次
make([]int, len(pattern))，GC 压力会明显上升 - UTF-8 处理是透明的：标准库按字节操作，语义正确；若你误在 KMP 中对
pattern做[]rune转换，就破坏了字节对齐逻辑，匹配结果错乱
next 数组构造最容易踩的边界坑
KMP 手写失败，90% 出在 next 构建阶段。核心错误不是算法逻辑，而是索引偏移和初始化。
-
next[0]必须为0—— 单字符无真前后缀；设成-1或未初始化，后续j = next[j-1]直接越界 - 循环里用
i, j := 1, 0是安全起点；但若写成j = next[j]（而非next[j-1]）就会跳错位置，比如"abababca"的next应为[0 0 0 1 2 3 4 0]，错一位就全崩 - 测试必须覆盖重叠 case：
buildNext("aaaa")应得[0 1 2 3]；若得[0 0 1 2]，说明while循环里j没及时更新或比较条件写反
真要手写 KMP，三个不可省略的控制点
只有当你需要复用模式串、获取全部重叠匹配、或做流式增量匹配时，才值得手写。这时必须显式管理这三点：
立即学习“go语言免费学习笔记（深入）”；
-
预计算
next并缓存：封装成type KMP struct { pattern string; next []int }，避免每次匹配都重建数组 -
匹配后跳转逻辑区分语义：想兼容
strings.Index（非重叠），匹配成功后设i = i - j + 1；想支持重叠（如"aaaa"查"aa"得0,1,2），则设j = next[j] -
失配回退严格用
j > 0 && pattern[j] != text[i]判断：漏掉j > 0条件，j-1就会负数索引；用pattern[i]比较（而非pattern[j]）是典型抄错伪代码
多模式匹配别硬改 KMP
KMP 是单模式算法。当你要同时查 5 个以上关键词（如敏感词过滤），循环调用 strings.Index 或手写多次 KMP，性能会断崖下跌。
-
regexp.MustCompile("a|b|c|d|e")在简单正则下，Go 会自动编译成类似 Aho-Corasick 的状态机，实测比循环快 3–5 倍 - 若需极致性能或自定义行为（如带权重匹配、模糊容错），再上 AC 自动机或 Bitap；KMP 强行拼多模式只会让代码难维护、边界更难控
- 注意
regexp的编译开销：应复用*regexp.Regexp实例，别每次匹配都MustCompile
真正容易被忽略的是：KMP 的“高效”只在模式串较长、文本串极大、且匹配失败频繁时才体现出来；日常小字符串查找，它的优势根本跑不出来，而 bug 却随时等着你。
