std::string::find 是循环查找的唯一可靠起点，需用 pos + sub.length() 避免重叠匹配遗漏；std::search 更通用但稍慢；KMP 仅适用于长文本高频查找；string_view 仅优化传参开销。
用 std::string::find 循环查找最直接
标准库没提供“一次性返回所有位置”的函数，std::string::find 是唯一可靠起点。它返回第一个匹配的起始索引，找不到时返回 std::string::npos，关键在于每次找到后把搜索起点移到匹配结束之后，避免重复或遗漏。
常见错误是把新起点设为 pos + 1 —— 这会导致重叠匹配被跳过（比如在 "aaaa" 中找 "aa"，应得 0,1,2，但 +1 只会得到 0,2）；正确做法是 pos + substring.length()。
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 初始化
pos = 0，然后进入while ((pos = str.find(sub, pos)) != std::string::npos循环 - 每次循环体内先记录
pos，再更新pos += sub.length() - 如果子串为空（
sub.empty()），find行为未定义，必须提前检查并拒绝
用 std::search 配合迭代器更灵活
当需要在 std::vector<char></char>、std::array 或自定义容器中查找，或想复用已有迭代器范围时，std::search 是更通用的选择。它接受一对迭代器作为主序列，另一对作为模式序列，返回指向首次匹配起始位置的迭代器，失败时返回末尾迭代器。
立即学习“C++免费学习笔记（深入）”；
和 find 不同，std::search 默认使用 operator==，但可传入自定义谓词（比如忽略大小写比较），这点在 std::string::find 中做不到。
实操建议：
- 头文件需包含
<algorithm> - 查找结果是迭代器，转成下标要用
std::distance(str.begin(), it) - 循环查找时，下次搜索范围应从
it + sub.length()开始，注意迭代器有效性 - 若用
std::search查std::string，性能略低于find（因额外函数调用和泛型开销），纯字符串场景优先选find
手动实现 KMP 能解决长文本+高频查找性能问题
当主串很长（MB 级）、子串较短但查找次数极多（比如日志解析、协议字段提取），find 的朴素 O(n×m) 时间可能成为瓶颈。KMP 算法预处理子串，使单次查找降到 O(n)，适合固定子串反复搜索的场景。
标准库不提供 KMP，必须手写或引入第三方（如 Boost.StringAlgo）。自己实现要注意：前缀函数（failure function）数组索引从 0 开始，计算时用 len = 0 和 while 循环回退，边界条件容易出错；且 KMP 不支持重叠匹配的“跳过长度”自由控制（比如想强制不重叠，得额外判断）。
实操建议：
- 只在 profiler 确认
find占用显著 CPU 时才考虑 KMP - 预处理子串一次，缓存
lps数组，避免每次查找都重建 - 测试用例必须覆盖边界：空串、单字符、全相同字符（如
"aaaa"找"aa"） - 多数项目用
find完全够用；KMP 是“知道它存在，但通常不用”的工具
注意 std::string_view 在 C++17+ 中能减少拷贝开销
如果原始字符串生命周期足够长，且只需读取（不修改），用 std::string_view 替代 std::string 传参，能避免构造临时 std::string 的开销。查找逻辑本身不变，但函数签名和调用侧更轻量。
常见误区是认为 string_view 能加速查找算法本身 —— 实际上它只是视图，底层仍调用相同逻辑；收益只在参数传递和子串切片环节。
实操建议：
- 函数参数优先声明为
std::string_view str, std::string_view sub - 调用
find时，string_view会隐式转换为std::string的兼容接口，无需改动查找逻辑 - 注意
string_view不拥有数据，确保其引用的原始内存不提前释放 - 在 C++17 之前无法使用，旧项目需保持
const std::string&
pos += sub.length() 还是 pos += 1，而文档里往往不强调这点。业务逻辑决定它，不是技术决定它。 
