next数组不能简单等同于最长公共前后缀长度，因其构建是依赖前序结果的动态推导过程，需双指针配合回退逻辑，初始化与边界处理稍有偏差即导致错误。
为什么 next 数组不能直接用「最长公共前后缀长度」一句话糊弄
因为构建过程不是静态查表，而是动态推导：每个位置的 next[i] 依赖前面已算出的 next[0..i-1] 和当前字符是否匹配。初学者常误以为“扫一遍模式串统计前后缀就行”，结果写出 O(m²) 的暴力版本，完全失去 KMP 的意义。
实操建议：
- 用双指针：一个指针
j指向当前已知最长前缀末尾（也是next[i-1]的值），另一个i遍历模式串索引 - 当
pattern[i] == pattern[j]，则next[i] = j + 1，然后i、j同时右移 - 不等时，
j不归零，而是回退到next[j-1]—— 这才是 KMP 的核心跳转逻辑 - 边界注意：
next[0]必须设为 0（或 -1，取决于实现风格），否则整个链式回退失效
next 数组两种主流初始化风格的区别在哪
差异本质是「匹配失败时指针如何移动」：一种让主串指针不动、模式串指针跳到 next[j]；另一种跳到 next[j] + 1。前者 next 定义为「真前缀真后缀最大长度」，后者常把 next[0] 设为 -1，后续比较前先自增。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 用 Python 写出
next全是 0 —— 很可能是初始化j = 0后没处理j == 0 and pattern[i] != pattern[j]的情况，导致j卡死 - 匹配时越界访问 —— 对应用了 -1 风格却没在循环里判
j == -1就直接pattern[j] - 性能影响：-1 风格少一次条件判断，但可读性略低；长度风格更贴近直觉，但循环内多一次
if j > 0
Python 实现 build_next 时最容易漏掉的三个细节
不是语法问题，而是语义陷阱。哪怕代码能跑通，错一处就可能让匹配漏掉正确位置或无限循环。
必须检查：
-
next数组长度必须等于模式串长度，不是len(pattern) + 1（除非你刻意做哨兵） - 内层 while 循环必须带
j > 0条件，否则j变成 -1 后继续pattern[j]会取到末尾字符，逻辑全乱 - 更新
next[i]的时机：只在pattern[i] == pattern[j]成立时赋值；若靠 while 跳出后j已为 0 且仍不等，next[i]就该是 0，别忘了这句赋值
简短示例（长度风格）：
def build_next(pattern):
m = len(pattern)
next_arr = [0] * m
j = 0
for i in range(1, m):
while j > 0 and pattern[i] != pattern[j]:
j = next_arr[j-1]
if pattern[i] == pattern[j]:
j += 1
next_arr[i] = j # 注意：这句不能放进 if 里
return next_arr
什么时候该放弃手写 next 改用内置方法
95% 的字符串匹配场景，根本不需要 KMP。Python 的 str.find()、in 操作底层是优化过的 Boyer-Moore 变种，对普通文本远快于手写 KMP；只有当你反复在固定长模式串上匹配海量文本，且 profiling 确认是字符串匹配瓶颈时，才值得投入。
真实权衡点：
- 模式串长度 == 或
find更快，函数调用开销都比 KMP 初始化小 - 模式串含大量重复字符（如 "aaaaab"）：KMP 优势明显；但若只是英文单词混合数字，Boyer-Moore 的坏字符跳转往往更高效
- 需要获取所有匹配起始位置：手写 KMP 可控性强；但
re.finditer()在简单字面量场景下更稳，不用自己管next边界
真正容易被忽略的是：KMP 的 next 构建本身有 O(m) 时间和空间成本。如果每次匹配都换不同模式串，这个预处理就成了负优化。
