std::string::find 通常采用优化的 Boyer-Moore 或双向扫描而非 KMP，平均性能好、安全性高、无需手动处理边界；仅在嵌入式或超长模式且需稳定最坏时间复杂度时才需手写 KMP。
为什么 std::string::find 不是 KMP，但你通常不需要手写 KMP
标准库的 std::string::find 在多数实现中用的是优化过的 Boyer-Moore 或双向扫描，并非 KMP；它平均快、可读性高、还自动处理空串和越界。除非你在嵌入式环境受限、或要匹配超长模式串（比如 >10KB）且对最坏时间敏感，否则真没必要自己撸 KMP。
手写 KMP 的典型误判是：以为“算法教科书写了，就得照搬”。实际中，std::string::find 对短模式（
computeLPS 函数里最容易漏掉的边界条件
LPS（Longest Proper Prefix which is also Suffix）数组构建时，核心陷阱是 j = 0 后还试图访问 pattern[j-1] —— 这会导致越界或逻辑错乱。
- 初始化
lps[0] = 0，从i = 1开始遍历 - 当
pattern[i] != pattern[j]且j > 0时才执行j = lps[j-1]；j == 0就直接设lps[i] = 0 - 别用
while (j > 0 && pattern[i] != pattern[j])后不检查j是否归零就继续比较 —— 容易跳过j == 0的分支
示例片段：
立即学习“C++免费学习笔记（深入）”；
lps[0] = 0;
int j = 0;
for (int i = 1; i < m; ++i) {
while (j > 0 && pattern[i] != pattern[j])
j = lps[j-1];
if (pattern[i] == pattern[j])
++j;
lps[i] = j;
}匹配过程中的指针推进逻辑为什么比预处理更难调
预处理出 LPS 后，主匹配循环看似简单，但 i 和 j 的推进节奏稍一错位，就会漏匹配或死循环。
-
i每轮必须递增（哪怕j回退），否则在pattern[j] != text[i]时卡住 - 只有
j == m才算找到一次匹配，此时应记录位置i - m，然后按j = lps[j-1]继续找重叠匹配（如模式"aa"在"aaa"中应匹配两次） - 若不需要重叠匹配，找到后直接
j = 0即可，但别忘了重置前先保存结果
常见错误现象：text = "ababababca", pattern = "abababca"，漏掉末尾匹配 —— 往往因为 j 没在 i 到末尾后做最后一次检查。
C++17 以后用 std::string_view 改写 KMP 能省什么
原生 std::string 传参默认拷贝，KMP 预处理阶段若频繁构造子串（比如切片 pattern），会触发内存分配。用 std::string_view 可避免。
- 把函数签名从
int kmp(const std::string& text, const std::string& pattern)改成int kmp(std::string_view text, std::string_view pattern) - LPS 数组仍需
std::vector<int></int>，但 pattern 访问变成pattern[j]（string_view支持随机访问） - 注意
string_view不拥有数据，确保传入的text和pattern生命周期长于 KMP 调用
性能影响：对大文本（MB 级）多次调用时，减少拷贝可降低 5%~15% 总耗时；但对小字符串，编译器常能优化掉拷贝，收益不明显。
KMP 的真正复杂点不在公式推导，而在 LPS 构建和匹配循环里那几行状态转移的“时机感”——j 什么时候该回退、什么时候该清零、什么时候该再试一次，差一行就全错。写完别急着测用例，先拿 "a"、"aa"、"abab" 这类极简模式过一遍边界。
