周传炽1. 从一次线上事故说起：字符串匹配为什么值得较真
我印象很深的一次经历，是很多年前做日志检索系统时遇到的一个诡异问题。当时的系统里跑着一个定时任务，每天要扫描几十GB的运营日志，从里面挑出包含指定关键词的样本行，再做后续统计。起初一切正常，但上线跑了一周后，任务越来越慢，最后甚至跑到凌晨都跑不完。排查下来，问题竟然出在一段不起眼的字符串匹配逻辑上——当时用的是Java String的indexOf，逻辑本身没错，但匹配的特征串里包含了大量“几乎相同但差一点”的内容，比如pattern_001、pattern_002这种长期重复匹配失败的场景，直接让朴素匹配的时间复杂度退化到了接近O(n*m)的极端水平。
这件事之后，我把字符串匹配的经典算法重新翻出来过了一遍，尤其是KMP算法。KMP是Knuth、Morris和Pratt三位计算机科学家在1977年提出的线性时间字符串匹配算法，它解决的核心问题非常朴素：在一个主串（Text）里查找模式串（Pattern）出现的位置，并且希望匹配效率不随模式串和主串的“局部相似”而大幅退化。
这篇博文不适合“背八股”的同学，它更适合真正要写代码、要处理真实数据的人。我会把KMP拆成几个层面：先从暴力匹配的痛点讲起，再讲清楚next数组到底在算什么、怎么手算、怎么写代码，最后把我在实际项目中踩过的坑和排查方法一并交代。你如果能跟着走完一遍，不仅面试时能从容讲清原理，更重要的是，以后在文本处理、日志分析、编辑器查找这些场景里，你能真正判断什么时候该用KMP，什么时候其实犯不上。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心思想与整体设计思路
2.1 为什么“不回溯主串”是关键
暴力匹配（BF算法）的逻辑很简单：从主串的每一个位置出发，依次和模式串的每一个字符比较，一旦发现某个字符不相等，就把模式串整体右移一位，主串的比较位置也回退到起始位置的下一位。代码写出来四五行的样子，但性能完全看命。
拿一个我当年排查过的日志场景举例：
主串 T = ABABABCABABABCABABABC
模式串 P = ABABAC
按朴素匹配，主串前5位ABABA能和模式串对上，第6位主串是B，模式串是C，不匹配。于是主串指针回退到第2位，再从第2位开始重新比对。接下来第2位是B，模式串第1位是A，上来就冲突；主串指针再前进到第3位……这些重复的比较中，绝大多数都是无效的，因为我们已经在前面那轮匹配中知道了主串第1到第5位的具体内容。
KMP的核心思想就一句话：已经比对过的信息，不要让主串指针白白丢回去重新比对。模式串向右滑动的距离，应该由“模式串自身的结构”来决定，而不是每次只滑一格。换句话说，主串指针只前进不后退，最坏情况下的时间代价从O(n*m)降到了O(n+m)，其中n是主串长度，m是模式串长度。
这个“不回溯”的思路，就是从“利用已知信息避免重复劳动”这个朴素想法里长出来的。它不依赖主串的内容，模式串一旦给定，我们就能预先算出一张“失配时该跳到哪里”的跳转表，也就是大家常说的next数组。
2.2 前缀、后缀与“已知信息复用”
要理解跳转表，先要理解两个概念：字符串的前缀和后缀。前缀是字符串除了最后一个字符外的任意头部连续子串，后缀是除了第一个字符外的任意尾部连续子串。注意，我们说的前缀和后缀都不包括字符串本身。
举个例子，模式串 ABABACA 的最大公共前后缀是几？我们把前缀列出来：A、AB、ABA、ABAB、ABABA、ABABAC；后缀列出来：A、CA、ACA、BACA、ABACA、BABACA。能看到，能同时作为前缀和后缀的只有一个字符A，所以它的最大公共前后缀长度是1。
KMP的匹配过程就是在反复利用这个长度。当模式串的某个位置失配时，主串从当前位置开始、模式串从失配位置往前的那些字符，都是已经和主串匹配成功的。如果模式串在失配位置之前的这部分子串里存在较长的公共前后缀，那就说明模式串的前缀部分已经和主串里“失配位置前的那一段”重叠了，我们完全可以直接把模式串滑动到这个前缀对齐的位置，而不需要主串指针回退。
你可能会问：为什么要挑“最长”的公共前后缀？因为挑最长的，滑动距离最小，不会漏掉中间可能存在的匹配机会。这是KMP保证正确性的关键：宁可多比几次，也绝不跳过潜在匹配点。
3. 核心细节解析：next数组的完整推导
3.1 next数组的两种定义，先别混淆
网上讲KMP的文章有个特别容易让人晕的地方：next数组的定义不统一。有的教材里，next[i]表示“模式串前i个字符组成的子串中，最大公共前后缀的长度”；有的教材里，next[i]表示“当第i位失配时，模式串应该跳到哪个下标继续比较”。两种定义就差一个偏移，但算出来的数组内容完全不同，初学时不注意就会看串行。
我个人建议这样区分：
- 定义A（偏移一位）：
next[j]表示模式串P[0..j-1]的最大公共前后缀长度。注意这里的下标 j 表示“当前失配位置”，而 next[j] 是“失配位置之前的子串”的信息。 - 定义B（直接跳转）：
next[j]表示P[0..j]的最大公共前后缀长度，并且实际使用时当P[j]失配就令j = next[j-1]来做下一轮比较。
两种定义最终都能写出正确的KMP，但你不能今天看一篇用定义A的，明天看一篇用定义B的，然后代码混着写，那样必出问题。下面我统一使用定义A，也就是绝大多数教材和面试官默认的版本：
next[i]的含义是：当模式串第 i 位（下标从0开始记）与主串不匹配时，模式串的指针 j 应该回退到next[i]这个位置，继续和主串当前字符比较。
在这种定义下，next[0] 在最开始就约定为 -1，表示模式串第一位都配不上，主串指针需要后移一位。next[i] 的值实际上就是 P[0..i-1] 的“最长相等前后缀长度”。注意这个细节：算的是 i 位之前的子串，不包含当前失配位本身。
3.2 模式串 p="abacaba" 的完整手算过程
我们拿一个比较经典的例子来手算一遍，模式串 P = abacaba。这个串的特点是有明显的前后缀重合，非常适合验证理解。
先把每一位的字符列出来：
| 下标 i | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|---|
| 字符 | a | b | a | c | a | b | a |
next[0] = -1，这是约定的初始值。- 当 i=1 时，看
P[0..0]，子串是a，单个字符没有真前缀真后缀，最大公共前后缀长度是0，所以next[1] = 0。 - 当 i=2 时，看
P[0..1]，子串是ab，前缀是a，后缀是b，不相等，所以next[2] = 0。 - 当 i=3 时，看
P[0..2]，子串是aba，前缀有a、ab，后缀有a、ba。能同时出现的是a，长度1，所以next[3] = 1。 - 当 i=4 时，看
P[0..3]，子串是abac，前缀有a、ab、aba，后缀有c、ac、bac，没有任何相等的前后缀，所以next[4] = 0。 - 当 i=5 时，看
P[0..4]，子串是abaca，前缀有a、ab、aba、abac，后缀有a、ca、aca、baca，相等的最长前后缀是a，所以next[5] = 1。 - 当 i=6 时，看
P[0..5]，子串是abacab，前缀有a、ab、aba、abac、abaca，后缀有b、ab、cab、acab、bacab，相等的最长前后缀是ab，长度2，所以next[6] = 2。
所以模式串 abacaba 的 next 数组是：[-1, 0, 0, 1, 0, 1, 2]。
如果面试官问你 p="abacaba" 的 next 数组，答案就是这个。注意这里有一个很容易犯的错：不要傻乎乎地把 next[3] 写成“当前字符 a 和开头 a 相等所以是1”，而是要看第3位之前的子串 ab 而非 aba。其实在上面这个例子里，next[3] 看的是 P[0..2] 也就是 aba，恰好和“当前字符”重合容易搞混。你只要记住一个原则：next[i] 永远只看 i 之前的字符，就不会被绕进去。
3.3 手算之外的递推求解：真正的KMP精髓
手算能帮你建立感性认识，但程序不可能每次匹配前去暴力枚举每个子串的前后缀，那样又回到了O(m^2)甚至更差。KMP的真正巧妙之处在于，next数组可以用一个类似动态规划的过程在O(m)时间内递推出来。
核心递推关系是这样：
假设我们已经知道 next[i] = k，意思是 P[0..k-1] 和 P[i-k..i-1] 相等。现在要计算 next[i+1]，我们需要看 P[k] 和 P[i] 是否相等。
- 如果
P[k] == P[i]，那么直接得到next[i+1] = k + 1。 - 如果
P[k] != P[i]，那么需要把 k 回退到next[k]，再继续比较P[k]和P[i]，直到 k 为 -1 或者找到相等的字符为止。
这个“回退 k 到 next[k]”的操作，和KMP主匹配里“失配后回退模式串指针”的思想是同构的。也就是说，求解next数组的过程，本质上就是模式串自己和自己做一次KMP匹配。这个角度一旦想通，KMP就算真正理解了。
写成伪代码就是：
java复制public static int[] buildNext(String pattern) {
int m = pattern.length();
int[] next = new int[m];
next[0] = -1; // 初始约定
int k = -1; // 当前最长公共前后缀长度减1
int i = 0;
while (i < m - 1) {
if (k == -1 || pattern.charAt(i) == pattern.charAt(k)) {
i++;
k++;
next[i] = k;
} else {
k = next[k]; // 回退
}
}
return next;
}
这里稍微解释一下为什么代码里的 k 初始是 -1，而不是0。因为 next 数组的定义里包含 -1 这个哨兵值，让 k 从 -1 开始，可以统一处理“没有公共前后缀”的情况。当 k 为 -1 时，说明连第一个字符都比不上，此时 next[i+1] 应该等于0，表现在代码里就是 i 和 k 同时加1，然后赋 next[i]=0，逻辑是自洽的。
4. 完整实现与匹配流程
4.1 KMP匹配主体逻辑
有了 next 数组，KMP 的匹配过程反而简单。两个指针：i 指向主串，j 指向模式串。每一轮比较：
- 如果 j == -1，说明模式串当前位置是“虚拟的 -1”，也就是模式串彻底要从头开始比，并且主串的指针需要向后移动一位。
- 如果 T[i] == P[j]，两个指针都前进。
- 如果不等，j 回退到 next[j]，i 不动。
匹配成功的时机是 j 走到模式串末尾，此时模式串在主串中对应起始位置是 i - j，注意因为找到了完整串，主串指针不需要回退，你可以继续往下找下一个匹配位置，这也是KMP在“找所有匹配位置”场景下依然高效的底气。
java复制public static List<Integer> kmpSearch(String text, String pattern) {
List<Integer> positions = new ArrayList<>();
if (pattern == null || pattern.isEmpty()) {
return positions;
}
int[] next = buildNext(pattern);
int i = 0; // 主串指针
int j = 0; // 模式串指针
int n = text.length();
int m = pattern.length();
while (i < n) {
if (j == -1 || text.charAt(i) == pattern.charAt(j)) {
i++;
j++;
if (j == m) {
positions.add(i - j);
j = next[j - 1];
// 注意这里不要 i--，继续往后匹配
// 实际上需要把 j 回退到 next[j-1]，因为 P[0..m-1] 匹配成功，
// 而 P[0..next[m-1]-1] 和后缀是相同的
if (j == -1) {
j = 0; // 避免出现 -1 下标
}
}
} else {
j = next[j];
}
}
return positions;
}
上面这段对“找到第一个匹配后继续查找”的处理，我用的是一个比较稳妥的写法：匹配成功后 j 回退到 next[m-1]，表示模式串前缀里和已匹配后缀重合的部分继续匹配。这里要小心，如果 next[m-1] 为 -1，需要把 j 重置为0，否则下一次循环 text.charAt(i) == pattern.charAt(j) 会访问 pattern[-1]，直接数组越界。这种细节不多跑几个用例根本发现不了，属于典型的“看起来对、跑起来炸”的坑。
4.2 一个完整的运行示意图解
还是用模式串 abacaba 和主串 ababacababacaba 来跑一遍。
主串 T = a b a b a c a b a b a c a b a
模式串 P = a b a c a b a
前3位 a b a 轻松匹配上，第4位主串是 b，模式串是 c，失配。此时模式串指针 j=3，查 next[3]=1，所以模式串从下标1（字符 b）开始跟主串当前位第4位（主串第4个字符 b）继续比较。
这一步实际上发生了什么？我们跳过了主串前3个字符中已经被验证过的部分，模式串的 a（下标0）默认和主串第3位（下标2）的 a 对齐了。因为 next[3]=1，意味着 P[0] 和 P[2] 相等，这个信息是从模式串结构里推出来的，不依赖主串内容。
接下来 b 对 b，匹配；再往后主串第5位是 a，模式串第2位是 a，匹配；主串第6位是 c，模式串第3位是 c，匹配；主串第7位是 a，模式串第4位是 a，匹配……一直匹配到模式串结束，找到一个完整匹配，position=2。
你会发现，主串指针在这个过程中是单调递增的，没有一次回退。这就是KMP“线性”的来源。而暴力匹配在这个例子里，第一次失配后会把主串指针回退到下标1去重新比，白白浪费了已经读取过的 ab 信息。
4.3 复杂度分析：为什么说它是O(m+n)
构建 next 数组的时间，模式串长度m，内部循环虽然看起来有 while 和 k=next[k] 嵌套，但 k 的值在整个构建过程中最多增加 m 次，回退的总次数也最多 m 次，所以均摊下来是O(m)。匹配过程同样，主串指针 i 最多增加 n 次，模式串指针 j 回退的总次数受限于前进步数，均摊也是O(n)。
所以整体时间复杂度是O(m+n)。空间上只需要一个长度为m的 next 数组，O(m)。
这里我要多说一句：很多人把“均摊的线性复杂度”理解成了“每一步都是线性的”，其实不对。KMP 中某个单次失配可能让 j 连续回退多次，比如模式串是 aaaaab、主串是 aaaaac 这种场景，第一次在最后一位失配时，j 会从5一路回退到 -1，这轮虽然看起来“多”，但后面主串指针每前进一位，模式串指针至多前进一位，总量仍然受控。你写代码时不用刻意优化这个回退过程，KMP的设计已经保证了总体线性。
5. 常见问题与排查技巧实录
5.1 最容易踩的坑：next数组定义混用
我见过太多人把“next数组”和“前缀函数”混为一谈，然后代码完全照搬，结果匹配结果死活不对。这里有一个非常显著的区分点：next[0] 是不是 -1。
如果某篇文章里 next[0] = 0，说明它用的是“前缀函数”定义，即 pi[i] 表示 P[0..i] 的最长公共前后缀长度。用这种定义写匹配时，失配回退要写成 j = pi[j-1]，并且要注意 j=0 时直接主串前进。两种定义都能用，但千万别在一个项目里换着用。我常用的办法是在代码注释里固定写清楚“next[i] 表示第 i 位失配时回退到的位置”，如果看到 next[0] 不是 -1，先停一下确认是哪种定义。
排查这类问题有个技巧：先找几个网上现成的测试用例验证 buildNext 的输出。比如模式串 abacaba，正确的 next 数组应该是 [-1,0,0,1,0,1,2]；如果算出来是 [0,0,0,1,0,1,2]，那就是定义混用了。
5.2 边界条件：空模式串、单字符模式串、全相同字符
边界条件是最容易在笔试和线上代码里翻车的部分。
- 空模式串：任何匹配的起始位置都有争议。工程上通常认为空串出现在第0位，但KMP的 next 数组没法构建，所以严判直接返回空列表比较稳妥。
- 单字符模式串
a：next 数组应该是[-1]，匹配时如果主串第一个字符就是a，j 走到1，立即找到匹配。但如果主串字符不是a，j 会被赋成 next[0]=-1，下一轮 i 前进。这个场景必须保证代码里j == -1的分支存在。 - 全相同字符模式串
aaaa：next 数组是[-1, 0, 1, 2]。这里有一个容易漏的地方：当P[3]失配，j=3 回退到 next[3]=2，如果再次失配又回到 next[2]=1，再回到 next[1]=0，最后 next[0]=-1。代码里的 while 循环会自动处理这种连续回退，但如果你手动化简匹配逻辑，很容易少写一层循环。
我建议写完 buildNext 之后，直接用 ${'a'.repeat(1000000)}b 这种大规模重复串测一下性能，确认没有退化到O(m^2)。实际项目中我遇到过自己实现的 KMP 在长重复模式下跑得极慢的情况，排查后发现是 buildNext 里用了 substring 或字符串拼接，导致每次回退都重新生成子串，复杂度被拉高了一个量级。
5.3 从报错场景看 KMP 的工程实现问题
这里借一个真实的报错场景扩展一下。在部分脚本语言或数据处理领域，你会看到类似 malformed version string、invalid multibyte string 之类的报错，这些虽然不是KMP直接相关，但背后的教训是通用的：字符串匹配算法对字符编码极其敏感。
KMP的 next 数组是基于“字符”构建的，如果模式串和主串的编码不一致，比如主串是 UTF-8 多字节字符，模式串确实 UTF-16 编码，逐字节比较就会产生误匹配。工程上处理中文或 emoji 时，建议统一转成 Unicode 码点数组后再跑KMP，或者直接使用语言内置的字符串匹配方法，因为很多内置方法已经处理了编码边界。
另一个隐患是字符比较的“单位”不一致。Java 的 char 是 UTF-16 的一个 code unit，对于 emoji 这种需要两个 code unit 的字符，直接用 charAt 做KMP会把一个字符拆成两半。解决思路是把字符串转成码点数组 int[] codePoints 再匹配。这个坑我在做短信内容过滤时踩过，模式串里包含一个表情符号，直接匹配怎么也匹配不上，后来转成码点数组才解决。
6. 从KMP出发：应用场景与变种
6.1 实际业务里KMP的用武之地
很多人觉得KMP就是面试考点，实际用不到。这其实是误解。字符串匹配在真实系统里无处不在，只是大多数时候被 JDK 的 indexOf 或正则引擎封装好了，你没直接调KMP而已。但理解KMP能帮你判断什么时候该用、什么时候不该用。
KMP最典型的应用场景：
- 文本编辑器/IDE 里的“查找”功能。虽然现代编辑器大多用了更快的算法，但基础实现里KMP是很好的起点。
- 日志关键词过滤。如果存在大量“部分匹配但最终失败”的日志模式，KMP能显著减少无效比较。
- DNA/基因序列匹配。序列长度动辄上亿，暴力匹配不可行，KMP是入门级别的解决方案。
- 数据去重、敏感词过滤、协议解析中的固定字段查找。
适合用KMP的场景有一个共同特点：模式串较长、且会有大量“接近匹配”但最后失配的情况。如果模式串很短（比如1-5个字符）或者主串很短，直接暴力匹配可能反而更快，因为KMP需要额外构建next数组，数组构建成本在小数据量下会超过节省下来的比较成本。
我个人的经验阈值是：模式串长度小于10时，直接用内置 indexOf；大于10且需要重复匹配多个主串时，优先考虑KMP或更高级的BM算法。这里没有绝对标准，建议自己在真实数据上做一个基准测试，别拍脑袋。
6.2 KMP与其它匹配算法的横向对比
KMP不是唯一的线性匹配算法，也不是在所有场景下都最优。
Boyer-Moore（BM）算法是从模式串尾部开始匹配，利用“坏字符规则”和“好后缀规则”跳过尽量多的字符。在模式串较长、字母表较大时，BM通常比KMP更快，因此很多文本编辑器实际用的是BM的变种。
Sunday算法是BM的简化版，关注主串中下一个参与对齐的字符，实现简单且平均性能很好。很多“手写字符串匹配”的博客推荐它，就是因为代码短、效果也不差。
Rabin-Karp算法则利用哈希，适合“多模式匹配”场景，例如在一篇文章中同时查找多个关键词。它用滚动哈希把每个子串的比较降到O(1)，但哈希冲突时还要回退到逐字符确认。
如果你要处理的数据量特别大、模式串数量特别多，那就不该只看单个算法了，可以考虑使用 Aho-Corasick 自动机（AC自动机）。AC自动机相当于在 Trie 树上做KMP的失配跳转，可以在一次扫描主串的同时匹配多个模式串，是敏感词过滤系统的核心算法。理解KMP的 next 数组后，再去看 AC 自动机的 fail 指针，会发现思路异曲同工，学习成本会低很多。
6.3 字符串拼接与内存布局：KMP之外的命题
有时候标题里挂着 KMP，大家讨论的却是 Java 的 String、StringBuilder、StringBuffer 的区别，这其实不奇怪。在 Java 中，字符串是不可变对象，每次拼接都会产生新的 String 对象，频繁拼接会带来大量GC压力。KMP 的 next 数组构建本身只需要读取模式串、不需要修改字符串，因此如果你在循环里用 += 拼接模式串或主串，反而会让算法的常数因子暴涨。
我做数据处理时常用的做法：如果需要在循环里逐步构造主串，优先用 StringBuilder；如果只是读取字符串内容做匹配，直接用原始 String 即可，KMP读取不会产生额外对象。另外，Java 9 之后 String 底层从 char[] 改成了 byte[] 加编码标志，对于纯ASCII字符串，存储更紧凑，这也是为什么你对比 KMP 在不同版本的 JVM 上运行性能会有差异。
如果你在 C++ 环境里做类似工作，建议先了解 std::string 的内存布局，避免在热循环里发生深拷贝。C++17 之后的 std::string_view 可以做到“只读不拷贝”地引用字符串片段，配合KMP做子串匹配时能省掉大量不必要的内存分配。这个细节在讨论“KMP的工程实现”时很少有人提，但实际性能调优时非常关键。
7. 实战扩展：把KMP封装成可复用工具
7.1 一个更健壮的封装思路
前面那段匹配代码只是“能跑”，离“可复用”还差得远。工程上我会再加一层封装，把 next 数组的构建缓存起来。因为实际业务中经常有“同一个模式串匹配多个主串”的需求，比如一个敏感词列表里的每条规则，要扫描所有用户评论。这时如果每条评论都重新构建一次 next 数组，那是在浪费CPU。
java复制public class KmpMatcher {
private final String pattern;
private final int[] next;
public KmpMatcher(String pattern) {
this.pattern = pattern;
this.next = buildNext(pattern);
}
/**
* 返回 pattern 在 text 中首次出现的起始下标，不存在则返回 -1
*/
public int indexOf(String text) {
if (pattern.isEmpty()) {
return 0;
}
int i = 0;
int j = 0;
int n = text.length();
int m = pattern.length();
while (i < n && j < m) {
if (j == -1 || text.charAt(i) == pattern.charAt(j)) {
i++;
j++;
} else {
j = next[j];
}
}
return (j == m) ? i - m : -1;
}
/**
* 返回所有匹配起始下标
*/
public List<Integer> findAll(String text) {
List<Integer> res = new ArrayList<>();
if (pattern.isEmpty()) {
return res;
}
int i = 0;
int j = 0;
int n = text.length();
int m = pattern.length();
while (i < n) {
if (j == -1 || text.charAt(i) == pattern.charAt(j)) {
i++;
j++;
if (j == m) {
res.add(i - m);
j = next[j - 1];
if (j < 0) {
j = 0;
}
}
} else {
j = next[j];
}
}
return res;
}
}
这个封装的好处是：构建一次 next，反复匹配。如果用同一个 KmpMatcher 实例执行多个主串的匹配，next 数组不会重复计算。我在日志分析工具里用了类似的封装，几千万行日志跑下来效果很稳定。
7.2 结合场景的调整：当模式串为多字符规则时
还有一种场景，模式串不是普通字符串，而是带通配符或正则语义的规则。比如 ab*cd 这种，不能直接套KMP，因为 * 表示任意字符。这时有两种做法：一种是先用KMP把固定子串找出来，再对通配符部分做辅助匹配；另一种是干脆用支持正则的库，内部已经优化过，不用重复造轮子。
从经验角度讲，如果只是简单的 * 通配，自己实现一个扩展KMP模式的复杂度并不高：把模式串按通配符切分成若干段，在每段上用KMP找下一个匹配位置，通配符长度随意匹配。但如果规则复杂、通配符种类多，那就直接用正则引擎，除非你有极端的性能瓶颈且明确知道瓶颈在正则匹配上，否则不要轻易手写。
7.3 关于优化：什么时候用 KMP，什么时候别用
写到这里，必须泼一盆冷水：KMP并不是字符串匹配的银弹。其核心优势体现在最坏情况下的稳定性，但很多真实数据并不容易触发暴力匹配的最坏情况。现代语言的字符串查找函数（比如 Java 的 indexOf）在 JDK 内部针对短模式做了向量化、自研优化，日常使用中通常已经足够。
我自己的判断标准是这样的：如果你在写一个通用工具，直接用语言内置的 indexOf 或正则；如果你明确知道性能瓶颈在大量“部分失配”的循环比较中，再考虑引入KMP或BM；如果你在面试，KMP是“讲清楚思路”的基本功，但别强求现场写出无bug实现，很多面试官其实更在意你能否分析出暴力匹配的最坏情况、能否解释“不回溯”的思想。
还有一个常见误区：为了炫技，在只有几百个字符的短字符串上用KMP。这种做法不仅不会更快，反而会因为 next 数组构建开销拖慢整体。遇到这种场景，老老实实用内置方法才是正道。
8. 写在最后的一点个人体会
我最早学KMP的时候，也跟很多人一样，觉得脑子里全是浆糊，尤其搞不懂为什么 next 数组求解里那个 k = next[k] 要一直回退。后来真正看懂了“求解 next 本质上就是模式串自己和自己匹配”之后，才恍然大悟。从那以后，我再没有背过KMP的代码——每次都能从“自己和自己匹配”这个直觉出发重新推导出来。
如果你正在准备面试或者面试官突然问你 p="abacaba" 的 next 数组，别慌，从定义出发：next[i] 描述的是第 i 位之前的子串。逐个字符展开，2分钟就能手算完。如果是在写代码，建议用我上面给的封装类，提前把 next 构建和匹配解耦，能把调试难度降低不少。
最后再分享一个亲测有效的小技巧：写完KMP后，不要只在简单用例上测试。用“全相同字符”模式串、用只差最后一位的模式串、用超长随机串压测一遍，很多隐蔽的越界和性能问题都是这么暴露出来的。字符串匹配这件事，看着基础，但真正下功夫抠过细节之后，你对数据结构的理解会明显上一个个台阶。