std::string_view能避免内存拷贝因其仅保存指针和长度而不拥有数据；构造时不复制，但要求原始数据生命周期足够长，否则易导致悬空指针。
std::string_view 为什么能避免内存拷贝
因为 std::string_view 不拥有字符串数据，只保存指向已有字符序列的指针和长度，构造时不做复制。只要原始数据（如 std::string、字面量、C 风格数组）生命周期足够长，string_view 就能安全引用它。
典型误用是把局部 std::string 的 c_str() 传给 string_view，然后函数返回后原始字符串析构，string_view 指向悬空内存——这不会编译报错，但运行时行为未定义。
函数参数用 const std::string_view& 还是 std::string_view
直接用 std::string_view（值传递）更合适。它本身只有两个成员（指针 + size_t），大小通常为 16 字节，比引用更轻量，且避免了引用带来的别名分析开销。现代编译器对这种小类型值传参优化得很好。
常见错误是写成 const std::string_view& 并以为“加 const 引用更安全”，其实反而可能阻碍内联或增加间接访问成本。
立即学习“C++免费学习笔记（深入）”；
- 接受字面量：
"hello"→ 自动转为string_view - 接受
std::string：s→s会隐式转换（不触发拷贝） - 接受 C 字符串：
c_str()可用，但必须确保其指向内存有效
什么时候不能用 std::string_view 替代 std::string
std::string_view 是只读视图，不能修改内容，也不能保证以 ' 结尾（虽然大多数场景下它是）；更重要的是，它不管理内存，所以任何需要字符串“拥有权”的场景都不能用。std::string_view 是只读视图，不能修改内容，也不能保证以 '\0' 结尾（虽然大多数场景下它是）；更重要的是，它不管理内存，所以任何需要字符串“拥有权”的场景都不能用。
以下情况必须用 std::string：
- 需要拼接、追加、替换等修改操作（
substr()返回新string_view，但不是原地修改） - 要存入容器并长期持有，而原始数据生命周期短于容器（例如缓存函数返回的局部字符串）
- 调用要求以 null 结尾的 C API（
string_view.data()不一定 null-terminated；可用s.data()[s.size()] == '\0'检查，但不保证） - 需要
.c_str()稳定返回（string_view没有c_str()成员）
std::string_view 的常见陷阱与性能注意点
最隐蔽的问题是隐式转换链过长导致意外拷贝。比如函数签名是 void f(std::string)，你传入 string_view，编译器会先用它构造临时 std::string ——这就白费了优化初衷。
另一个坑是误用 string_view 的比较操作：它基于字符逐个比较，但若传入非 null-terminated 数据（比如从二进制 buffer 截取），且中间含 '\0'，== 仍会比到 length 指定位置，不会提前终止；这点和 strcmp 不同，需心里有数。
示例：安全截取子串并避免越界
std::string_view s = "hello world"; std::string_view sub = s.substr(0, 20); // 即使 20 > s.size()，也不会越界，sub.length() = s.size() // 不需要手动 min(20, s.size())
真正容易被忽略的是：string_view 的 data() 指针有效性完全依赖用户保障。没有运行时检查，出问题就是段错误或静默数据错乱——它高效，但不宽容。
