直接手写 kmp 容易失败主因是 next 数组构建错误：误用暴力比较导致 o(m²) 复杂度，正确做法是用 dp 复用 next[i-1]，初始化 next[0]=0，j 从 0 开始按匹配/失配规则更新。
为什么直接手写 kmp_search 容易匹配失败？
多数人实现 KMP 时卡在 next 数组（也叫 lps）构建逻辑上：把“最长真前缀 = 最长真后缀”当成字符串比较来硬算，结果时间复杂度退化成 O(m²)，还容易漏掉边界情况。真正关键的是用动态规划思想复用已知信息——next[i] 的值依赖 next[i-1] 和当前字符是否匹配。
实操建议：
-
next[0]必须初始化为 0，不能跳过 - 构建时用
j指向当前已知最长前缀长度，每次失配不是重置j=0，而是回退到next[j-1] - 当
pattern[j] == pattern[i]时才递增j，否则持续回退，直到j==0或匹配成功
如何避免 std::string::find 无法满足的场景？
标准库的 find 只返回首个位置，且不暴露匹配过程。如果需要统计所有匹配起始索引、支持自定义字符比较（比如忽略大小写）、或对接硬件加速（如 SIMD 预筛选），就必须自己控制匹配循环。
实操建议：
- 主匹配循环中，用
i遍历文本，j跟踪模式串位置；每次j == pattern.length()就记录i - j，然后按next[j-1]重置j继续找下一个 - 若需忽略大小写，把
text[i]和pattern[j]都转成小写再比较，别在next构建阶段做转换 - 避免在循环内反复调用
pattern.length()，提前存入变量
为什么 next 数组用 vector<int></int> 而不用 int[]？
模式串长度未知，栈上分配 int next[1000] 既不安全也不通用；而 vector 自动管理内存，且访问性能和原生数组一致（编译器会优化掉边界检查）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
- 声明为
vector<int> next(pattern.size(), 0)</int>，确保大小匹配且初始化为 0 - 构建
next时下标从 1 开始（i = 1），因为next[0]已固定为 0 - 不要用
push_back动态扩容，先 resize 好，否则可能触发多次内存重分配
调试时最常见的三个 index out of bounds 场景
KMP 的指针操作密集，越界往往发生在回退逻辑里，而不是主循环外。
常见错误现象与修复：
-
j回退到 -1 后继续访问next[j-1]→ 检查每次j > 0才执行回退 - 匹配成功后
j未重置，导致下次循环pattern[j]访问越界 → 成功后应设j = next[j-1]（注意判j > 0） - 构建
next时i超出pattern.size()→ 循环条件必须是i ，不是 <code>
实际写的时候，所有数组访问前加 assert(j >= 0 && j 能快速暴露问题，上线前删掉即可。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
