std::string_view不能直接当std::string用，因为它不拥有数据，仅提供对已有内存的只读视图；绑定临时对象或短生命周期字符串会导致悬垂指针，引发未定义行为。
string_view 为什么不能直接当 string 用
因为 std::string_view 不拥有字符串数据，它只是对已有内存的一段“只读视图”。你传入一个临时 std::string 的 c_str() 给它，或者用字面量初始化没问题；但一旦原始数据被销毁（比如函数返回局部 std::string，你取它的 substr() 再转 string_view），string_view 就指向了野内存——运行时可能没报错，但读到垃圾值或崩溃是早晚的事。
- 常见错误现象：
string_view在函数返回后访问内容，结果为空、乱码、或Segmentation fault - 安全用法：只绑定生命周期明确且长于
string_view自身的对象，例如全局字符串字面量、类成员std::string、或函数参数中传入的 const 引用 - 别这么写：
string_view sv = some_func().substr(0, 5);——some_func()返回的临时string在分号结束就析构了
传参时用 string_view 替代 const string& 真能省拷贝吗
能，而且省得干净。只要调用方传的是字符串字面量、char*、std::string 或其他兼容容器，string_view 构造几乎零开销（仅存两个指针）。而 const std::string& 虽不拷贝数据，但要求调用方必须提供 std::string 对象——如果传的是字面量，编译器得先隐式构造一个临时 std::string，这就触发了一次堆分配和复制。
- 性能影响：对短字符串尤其明显。一次隐式
std::string构造可能比 memcpy 还贵 - 兼容性：支持所有可转换为
string_view的类型，包括 C 风格字符串、std::array<char n></char>、甚至自定义容器（只要提供data()和size()） - 注意点：如果你函数内部需要修改内容、或需要
capacity()/reserve()这类能力，就不能用string_view—— 它天生只读
string_view 的 substr() 和 string 的 substr() 行为差异
两者都返回子串，但语义完全不同：std::string::substr() 返回一个新分配的 std::string 对象；而 std::string_view::substr() 只返回另一个 string_view，不分配、不复制，只是调整内部指针和长度。
- 使用场景：频繁切片（比如解析 CSV、HTTP header）时，用
string_view::substr()避免反复堆操作 - 参数差异：两个函数都接受
pos和count，但string_view::substr()在越界时行为更宽松——超出长度时自动截断，不会抛异常（std::string::substr()会抛std::out_of_range） - 容易踩的坑：
sv.substr(100)如果sv.size() ，结果是空 <code>string_view（data() == nullptr不成立，但size() == 0），不是崩溃，但可能掩盖逻辑错误
string_view 在容器里存着安全吗
不安全，除非你能 100% 控制所指向数据的生命周期。把 string_view 存进 std::vector、std::map 或类成员里，等于把“悬空风险”打包保存了。
立即学习“C++免费学习笔记（深入）”；
- 典型翻车现场：把局部
std::string的string_view存进全局std::vector<string_view></string_view>，函数退出后全失效 - 替代方案：如果必须持久化，要么存
std::string（确定要拷贝），要么用智能指针管理原始数据（复杂度飙升），要么改用索引+大缓冲区（如 arena allocator） - 一个容易被忽略的细节：
string_view的data()可以是nullptr（比如默认构造或空切片），但很多旧代码假设非空，直接解引用会崩
string_view 把这个责任明明白白甩给了你。 
