std::string_view传参比const std::string&快在避免临时string构造开销，仅持指针+长度（16字节拷贝），而后者可能触发内存分配与拷贝；适合只读且生命周期可控场景，禁用于修改或需拥有的操作。
std::string_view 传参比 const std::string& 快在哪？
直接说结论：std::string_view 避免了构造临时 std::string 对象的开销，尤其在函数频繁调用、参数只是读取时优势明显。它不拥有数据，只持有一对指针（const char* + size_t），拷贝成本固定为 16 字节（典型实现），而 const std::string& 虽然也是引用，但调用方若传入字面量或 C 风格字符串，编译器常需隐式构造 std::string —— 这会触发内存分配（小字符串优化虽缓解但不消除）和字符拷贝。
哪些场景适合改用 std::string_view？
不是所有字符串参数都适合换。关键看两点：函数内部是否只读、参数来源是否生命周期可控。
- ✅ 适合：
void log_message(std::string_view msg)、bool ends_with(std::string_view s, std::string_view suffix)、std::optional<:string_view> find_substring(std::string_view haystack, std::string_view needle)</:string_view> - ❌ 不适合：
void append_to_buffer(std::string_view s)（函数要修改内容）、std::string make_path(std::string_view base, std::string_view name)（需要拼接并返回新字符串，string_view无法持有拼接结果） - ⚠️ 危险：
std::string_view持有栈上局部数组、临时std::string的c_str()结果（如f(std::to_string(x).c_str())），因为临时对象在完整表达式结束后销毁，string_view变成悬垂指针
std::string_view 构造时容易踩的坑
构造本身廉价，但隐式转换和生命周期陷阱极多。
-
std::string_view从const char*构造时，默认调用strlen推断长度 —— 若传入非 null-terminated 字符串（比如二进制数据），会越界读取直到遇到\0，引发未定义行为。必须显式传入长度：std::string_view{data, len} - 字面量自动转
string_view是安全的（编译期确定生命周期），但std::string的c_str()返回的指针仅在其对象生命周期内有效；若string是临时对象，string_view立刻失效 - 不要用
string_view存储跨函数边界的字符串引用，除非你 100% 控制其源头生命周期（例如只接受全局字符串、静态缓冲区、或明确由调用方保证存活的参数）
和 const char* 比，string_view 好在哪？
核心是「带长度的只读视图」带来的确定性和安全性。
立即学习“C++免费学习笔记（深入）”；
-
const char*必须配合额外长度参数才能安全处理二进制数据或含\0的字符串；std::string_view内置长度，.data()和.size()总是匹配 -
string_view支持.substr()、.find()、.starts_with()（C++20）等成员函数，语义清晰，无需手动计算偏移 - 与
std::string互操作友好：std::string{sv}可构造副本，sv == "abc"可直接比较，避免strcmp或std::string(s).compare("abc") - 注意：
string_view不提供.c_str()，需要 C 接口时仍得转std::string或确保源数据以\0结尾
真正难的不是怎么写 string_view 参数，而是判断哪一段字符串的生命周期你能兜住——这往往需要通读调用链，而不是只看函数签名。
