Go标准库strings.Contains通常比手写KMP更快，因其根据输入动态选择算法：小模式用SIMD指令（如memchr），中等长度用优化Boyer-Moore，长模式fallback类似KMP逻辑；而手写KMP需O(m)建next数组，开销反超。
Go 标准库的 strings.Contains 在绝大多数场景下比手写 KMP 更快，直接用它就行；只有在极少数明确知道模式串重复性强、且需频繁复用同一模式串做大量匹配时，才值得自己实现 KMP。
为什么 strings.Contains 通常比手写 KMP 还快？
Go 运行时对字符串查找做了深度优化：小模式串走 SIMD 指令（如 memchr），中等长度用优化版 Boyer-Moore，长模式串自动 fallback 到类似 KMP 的状态机逻辑。它不是简单封装朴素算法，而是根据输入长度、字符分布、CPU 架构动态选型。
手写 KMP 要先构建 next 数组（O(m) 时间 + O(m) 空间），再做一次扫描（O(n)）。而标准库在多数常见 case（比如查 "http"、"error"）里根本不走这部分逻辑，直接用硬件加速指令一枪命中。
- 实测：在 1MB 文本中查找 5 字符子串，
strings.Contains比自实现 KMP 快 2–3 倍 - 例外：模式串长达上千字符、且含大量前缀/后缀重复（如
"aaaaabaaaaab..."），KMP 的渐进优势才可能显现 -
strings.Index和strings.Contains底层共用同一套引擎，行为一致
手写朴素算法最容易踩的边界坑
自己实现暴力匹配时，for i := 0; i 这行代码在 <code>len(needle) == 0 时会 panic：负数不能用于无符号比较。Go 的 len 返回 int，但切片长度是无符号底层表示，编译器不报错，运行时崩溃。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式判断
if len(needle) == 0 { return true } - 循环条件改用
i+len(needle) ，避免整数溢出或负值比较 - 内层循环用
for j := 0; j ，别用 <code>j —— 后者在空串时又触发 <code>-1下标 - Go 字符串是 UTF-8 编码，但
strings.Contains按字节匹配；若需 rune 级语义匹配（如查中文词），得先转[]rune，此时朴素和 KMP 都要重写，性能差距反而缩小
KMP 的 next 数组构造为何常写错？
网上很多 Go 实现把 next[0] 设为 0 或 -1，但实际行为取决于主匹配循环里的条件分支。标准 KMP 主循环一般写成：
for i < len(haystack) && j < len(needle) {
if j == -1 || haystack[i] == needle[j] {
i++
j++
} else {
j = next[j]
}
}
这时 next 数组必须以 -1 开头，否则 j == -1 分支永远不触发，失配时无法重置。
- 构造
next时，next[0] = -1是强制约定，不是可选项 - 常见错误：用
next[j] = k表示“最长相等真前后缀长度”，但主循环却按“跳转目标索引”用 —— 二者语义不同，混用必错 - 测试用例一定要包含全相同字符（
"aaaa"查"aa"）和全不同字符（"abcd"查"xyz"），否则漏掉边界逻辑
KMP 真正难的不是代码，是理解“为什么这个 next 值能跳过哪些比较”；而生产环境里，你更常遇到的是内存对齐、GC 压力、或误把字节索引当 rune 索引用 —— 这些问题跟算法无关，但比 next 数组更早让你线上报警。
