go 中应直接使用 strings.index 而非手写 kmp，因其底层已优化实现；手动实现仅适用于教学或特殊需求，且易在 fail 数组、边界处理、编码兼容性等方面出错。
Go 语言里别手写 KMP，strings.Index 就是它
Go 标准库的 strings.Index 底层在多数情况下（长度适中、无极端退化）已用优化版 KMP 或更优算法（如 Rabin-Karp + fallback）实现，不是朴素匹配。你手动重写 KMP 几乎只会在教学或极特殊场景（比如要暴露部分匹配位置、做流式匹配）才有意义。
常见错误现象：strings.Index 返回 -1 时误以为“算法失效”，其实是真没匹配上；或者拿它和自己写的朴素循环比性能，发现“差不多”，就以为“KMP 没用”——其实 Go 的实现早就在小字符串走 memchr，大字符串才切到 KMP 类逻辑。
- 使用场景：日常子串查找、配置解析、日志关键词提取，直接用
strings.Index或strings.Contains - 参数差异：
strings.Index(s, substr)要求substr非空，传空串会 panic；而你自己写的 KMP 可能没处理边界，一跑就崩 - 性能影响：自己实现的 KMP 若没做内存复用（比如每次 new fail table），在高频调用下 GC 压力明显高于标准库
真要手写 KMP，fail 数组初始化最容易错
KMP 的核心是 fail 数组（也叫 lps），但很多人照着伪代码写，把索引偏移搞混，导致 fail[0] 设成 0 后，后续全错位——结果是匹配漏掉前缀，或越界访问。
正确做法是：用 0-based 索引，fail[i] 表示 substr[0:i+1] 的最长真前后缀长度，且 fail[0] 必须为 0（单字符无真前后缀）。别抄 Python 版本里常见的 1-based 写法然后硬套进 Go。
- 常见错误现象：
fail数组生成后，substr = "aaaa"得到[0 1 2 3]是对的；若得到[0 0 1 2]，说明 while 循环里没及时更新j，或者比较时用了substr[i] == substr[j+1]这种越界写法 - 实操建议：写完先跑
"abababca"和"abcabcabc"这类经典 case，比对fail值是否和维基百科一致 - 兼容性影响：Go 的
string是只读字节序列，KMP 过程中别试图转[]rune——那是按 Unicode 处理，和 KMP 字节匹配逻辑冲突；除非你明确要支持多字节字符的“语义匹配”，那 KMP 本身就不适用
多个模式匹配？别硬改 KMP，换 regexp 或 Aho-Corasick
KMP 是单模式算法，强行改成多模式（比如遍历每个 pattern 调用一次 strings.Index）在 pattern 数量 > 5 且文本很长时，性能断崖下跌。这时候 regexp 包的 MustCompile 对简单正则（如 "a|b|c"）会自动编译成类似 Aho-Corasick 的状态机，比循环调用快一个数量级。
- 使用场景：日志过滤规则、敏感词检测、协议头解析（如 HTTP header 名称匹配）
- 参数差异：
regexp.MustCompile("foo|bar|baz")比写三个strings.Contains更简洁，且失败时 panic 明确；但注意正则有开销，纯字面量匹配优先用strings.Index - 容易踩的坑：用
.*开头的正则去匹配长文本，会触发回溯爆炸；应尽量用锚点（^,$）和原子组约束
strings.Index 不返回所有匹配位置，需要自己循环
标准库没有 strings.FindAllIndex 这种函数（只有 strings.FieldsFunc 或正则的 FindAllStringIndex），所以想拿到全部匹配起止位置，得靠 strings.Index 配合切片推进——但这里有个隐形陷阱：匹配内容可能重叠，比如在 "aaaa" 中找 "aa"，不处理好会漏掉中间两个。
- 实操建议：每次找到后，下一轮搜索从
start + 1开始（非重叠则用start + len(substr)） - 示例：
for i := 0; i
- 性能影响：重叠匹配时，循环次数接近 O(n×m)，退化成近似朴素算法；如果确定不需要重叠，+
len(substr)能大幅提速
真正难的不是 KMP 原理，而是判断什么时候该用标准库、什么时候该换正则、什么时候连正则都不够得上专用库（比如 github.com/BobuSumisu/aho-corasick）。这些决策点，比背熟 fail 数组推导公式重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
