最直接常用的是std::string::find，正确判断用!=std::string::npos；高频大文本优先string_view::find；忽略大小写等定制需求用std::search；极端性能场景慎用strstr。
std::string::find 是最直接、最常用的选择
绝大多数场景下，直接用 std::string::find 就够了。它语义明确、无需额外头文件、编译器优化充分，底层通常已内联或使用 Boyer-Moore 类算法加速。
常见错误是拿返回值跟 -1 或 0 比较：
-
s.find("abc") == -1—— 错：返回类型是size_t（无符号），-1会转成极大值，比较永远为假 -
s.find("abc") == 0—— 错：这只能判断是否在开头，不是“是否存在”
正确写法只有一种：
if (s.find("abc") != std::string::npos) { /* 包含 */ }
注意：std::string::npos 是静态常量，不是宏，不能写成 string::npos（缺 std:: 前缀）或 std::string.npos（点号错，应为双冒号）。
立即学习“C++免费学习笔记（深入）”；
高频调用或大文本时优先用 std::string_view::find
当你的字符串来源是字面量、const char*、函数参数中的 const std::string&，且生命周期可控时，std::string_view 能避免构造临时 std::string 的拷贝开销。
示例对比：
// 不推荐：每次调用都隐式构造 string 对象
bool contains(const char* s, const char* sub) {
return std::string(s).find(sub) != std::string::npos;
}
<p>// 推荐：零拷贝，仅持指针+长度
bool contains(std::string_view sv, std::string_view sub) {
return sv.find(sub) != sv.npos;
}
关键限制：
- C++17 起才支持，老项目需确认编译器（GCC 7+/Clang 5+/MSVC 2017+）
-
std::string_view不拥有数据，传入的原始内存必须在整个查找过程中有效；别把局部std::string的.c_str()传给长期存活的string_view - 空字符串字面量
""可安全用于string_view，但nullptr不行（string_view(nullptr)是未定义行为）
需要忽略大小写或自定义匹配逻辑时用 std::search
std::string::find 和 string_view::find 都是严格字节匹配，不支持忽略大小写、Unicode 比较或部分规则匹配。
这时该上 std::search，它接受任意迭代器范围和可选谓词：
#include <algorithm>
#include <cctype>
<p>bool case_insensitive_contains(std::string_view sv, std::string_view sub) {
auto it = std::search(sv.begin(), sv.end(),
sub.begin(), sub.end(),
[](char a, char b) {
return std::tolower(a) == std::tolower(b);
});
return it != sv.end();
}
注意点：
- 必须包含
<algorithm> - 谓词函数签名必须是
bool(char, char)，不能捕获外部变量（除非用 lambda 捕获，但要注意生命周期） - 性能略低于
find（泛型迭代器开销 + 每次调用谓词），只在真有定制需求时用
极端性能敏感场景慎用 strstr
如果字符串确定以 \0 结尾、只读、且你愿意放弃类型安全，strstr 是开销最小的选项：无异常、无分配、纯 C 实现、缓存友好。
用法很简单：
const char* s = "hello world";
if (strstr(s, "world") != nullptr) { /* 包含 */ }
但风险明显：
- 传入非空终止字符串（如来自
std::string::data()但未保证结尾为\0）会导致越界读 - 不检查
nullptr输入：传nullptr给strstr是未定义行为 - 无法处理含
\0的二进制字符串（std::string允许中间有\0，strstr会提前截断）
真正值得用 strstr 的地方极少，通常是嵌入式或网络协议解析中对已知格式的 HTTP 状态码、固定报文头做快速扫描。
最容易被忽略的其实是生命周期问题：用 string_view 时，没人会主动检查它引用的内存是否还活着；而 find 返回的 size_t 值一旦误判为布尔，后续用这个“位置”去访问字符串就会崩溃。这两个点，比选哪个函数更重要。
