std::search 不保证使用 Boyer-Moore，实际多为朴素匹配或优化KMP；C++17 的 std::boyer_moore_searcher 需配合专用 search 重载使用，且构造有开销、不适用于短模式或 UTF-8 文本。
std::search 默认不使用 Boyer-Moore
直接说结论：std::search 在标准库实现中**不保证**用 Boyer-Moore，绝大多数编译器（libstdc++、libc++）实际用的是朴素的双向匹配或优化版 KMP 变种。它只是语义上“找子序列”，不暴露算法选择权。
想用 Boyer-Moore，必须绕过 std::search，自己集成或调用支持该算法的第三方实现。
- MSVC 的
std::search在小模式串时可能做 short-circuit 优化，但不是 BM - libstdc++ 使用类似
std::find_first_of的逐字符推进逻辑，最坏 O(n×m) - 即使你传入随机访问迭代器，
std::search也不自动升級为 BM —— 它没这个机制
用 std::boyer_moore_searcher 需 C++17 且手动构造
C++17 引入了 std::boyer_moore_searcher 和 std::boyer_moore_horspool_searcher，但它们**不能直接喂给 std::search**；必须配合 std::search 的重载版本（接受 searcher 对象）。
常见错误是写成 std::search(first, last, pattern.begin(), pattern.end(), searcher) —— 这会编译失败，因为那个三参数 std::search 不接受 searcher。
立即学习“C++免费学习笔记（深入）”；
- 正确调用形式是：
std::search(first, last, searcher)，其中searcher是std::boyer_moore_searcher实例 -
searcher构造时需传入模式串的迭代器范围，内部预计算坏字符表，所以**构造有开销**，适合多次搜索同一模式 - 若模式串极短（如 1–3 字符），BM 表预计算反而拖慢，此时
std::search的朴素实现可能更快
std::string text = "abacabadabacaba"; std::string pattern = "daba"; std::boyer_moore_searcher bm(pattern.begin(), pattern.end()); auto it = std::search(text.begin(), text.end(), bm); // ✅ 正确
Boyer-Moore 在 C++ 中的实际性能陷阱
BM 理论最坏 O(n/m)，但实际表现严重依赖字符集和模式特征。在 C++ 标准库实现里，有两个常被忽略的限制：
-
std::boyer_moore_searcher要求RandomAccessIterator，且元素必须支持==；对std::string_view或std::vector<uint8_t></uint8_t>没问题，但对自定义类型要小心比较语义 - 它内部用
std::unordered_map或数组建坏字符表，若模式含大量不同字符（比如 UTF-8 编码的中文混排），空间占用暴涨，且哈希冲突会影响跳转效率 - 对于二进制数据（如
std::vector<:byte></:byte>），部分标准库实现未充分测试，libstdc++ 13 之前甚至会静默退化为线性扫描
替代方案：什么时候该放弃标准库 searcher
如果你需要稳定、可控、高性能的 Boyer-Moore，尤其是处理长文本+固定模式（如日志关键词扫描、协议解析），标准库的 searcher 往往不如轻量第三方：
-
abseil的strings::BoyerMooreSearch支持大小写不敏感和自定义字符映射 - 手写简化版 BM（仅坏字符规则，无好后缀）不到 50 行，可 inline、可 SIMD 优化，比通用 searcher 更快
- 对 Unicode 文本，别碰
std::boyer_moore_searcher—— 它按字节操作，无法识别码点边界，容易切碎 UTF-8
真正难的从来不是“怎么调 API”，而是判断当前场景下，预计算开销、内存局部性、字符分布是否真的让 BM 比一次 memcmp + find 更值。这点很容易被 benchmark 数据带偏。
