kmp算法理论复杂度o(n+m)，但日常开发应优先使用原生indexof/includes，因其经v8等引擎深度优化，实际性能更优、代码更简洁可靠；仅在特定边界场景（如多次匹配不同模式串、超长重复模式串）才考虑kmp。
JavaScript中字符串匹配，KMP算法在特定场景下比原生indexOf或includes更高效，但日常开发中几乎不需要手动实现——原生方法底层已高度优化，且多数情况更简洁、更可靠。
原生方法实际性能通常更好
现代JavaScript引擎（V8、SpiderMonkey等）对String.prototype.indexOf、includes、search等做了深度优化，例如：
- 短字符串常使用快速的逐字节比较或 SIMD 指令加速
- 长模式串可能自动切换为类似Boyer-Moore的跳转策略，而非朴素O(n×m)遍历
- 内置方法由C++实现，无JS调用开销，避免了KMP中显式的next数组计算与JS循环迭代成本
KMP的优势只在可控边界下显现
KMP的理论时间复杂度为O(n + m)，适合以下少数情况：
- 需多次在**同一主串**中匹配**不同模式串**（可预处理主串，但标准KMP不支持；需改造为后缀数组或AC自动机）
- 模式串极长且含大量重复前缀（如
"aaaaa...ab"），朴素匹配退化严重，而KMP能稳定线性 - 运行环境受限（如某些嵌入式JS引擎未优化字符串方法），且你完全掌控输入规模与特征
但注意：手写KMP在JS中创建数组、频繁访问索引、函数调用等，实际可能比V8内建的indexOf慢2~5倍（实测10万字符主串+100字符模式串，V8快约3倍）。
别为了“算法正确”牺牲可维护性
除非你在写底层文本编辑器、正则引擎或参加算法竞赛，否则：
- 用
str.indexOf(pattern) !== -1判断存在性，清晰且极速 - 需要全部匹配位置？
str.matchAll(new RegExp(escapeRegExp(pattern), 'g'))或循环调用indexOf（从上一位置+1开始）更直观 - 模式含特殊字符？务必先
escapeRegExp，而不是自己实现KMP去绕过正则——那只会引入bug和维护黑洞
真正该关注的性能瓶颈往往不在这里
字符串匹配极少是Web应用的性能瓶颈。更值得检查的是：
- 是否在循环中反复创建正则对象（应提取为常量）
- 是否用
RegExp匹配超长日志文本却未设超时或截断 - 是否误将大JSON字符串用
includes搜索，而本该解析后按字段查 - 是否在UI线程做MB级文本的全文匹配（应移交Worker或分块处理）
工具永远服务于问题——不是所有O(n)都比O(n²)快，也不是所有“高级算法”都比一行原生调用更合适。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
