std::string_view指向的内存必须比它活得久，否则会形成悬垂视图导致未定义行为；它不拥有数据，仅存储const char*和size_t，常见错误包括返回局部string的view、用临时string初始化参数、与std::string混用时忽略生命周期。
std::string_view 指向的内存必须比它活得久
这是所有问题的根源。std::string_view 不拥有数据，只存两个成员：const char* 和 size_t。一旦它所指向的原始字符串（比如局部 std::string、字面量临时对象、函数返回的临时 std::string）被销毁，string_view 就变成悬垂视图——读取时可能崩溃或返回垃圾值。
常见踩坑场景：返回局部 string 的 view
最典型错误是函数里构造一个 std::string，然后返回它的 string_view：
std::string_view bad() {
std::string s = "hello";
return s; // ❌ 隐式转换成 string_view，但 s 函数结束就析构
}
调用方拿到的 string_view 指向已释放栈内存。编译器通常不报错，运行时行为未定义。
- 改法：要么返回
std::string（代价可控，现代编译器常优化掉拷贝） - 要么确保源字符串生命周期足够长——比如传入的参数是
const std::string&或静态字符串字面量 - 注意：
"hello"是静态存储期，std::string_view{"hello"}安全；但std::string{"hello"}.substr(0,3)返回的是临时std::string，再转string_view就危险
std::string_view 作为参数时的隐式延长陷阱
你可能觉得“传参没问题”，但 C++ 允许用字面量或临时 std::string 初始化 string_view 参数，这时临时对象的生命周期只延长到整个表达式结束，不是整个函数作用域：
立即学习“C++免费学习笔记（深入）”；
void f(std::string_view sv) {
// sv.data() 可能指向已销毁的临时对象！
}
f(std::string("abc").substr(1)); // ❌ substr 返回临时 string，生命周期只到分号
这种写法在调试模式下常侥幸通过，上线后偶发崩溃。
- 安全做法：显式创建持久对象，比如
std::string s = "abc"; f(s.substr(1)); - 或者改用
std::string_view接收字面量、已有字符串引用，但绝不接收临时std::string衍生结果 - Clang/GCC 加
-Wdangling-gsl或-Wlifetime（C++20 实验性）能捕获部分这类问题
和 std::string 混用时的隐式转换风险
std::string_view 能隐式从 const char* 和 std::string 构造，但反向不行。容易误以为“它跟 string 一样稳”：
- 把
string_view存进容器（如std::vector<:string_view>），却没保证所有源头字符串全局/静态/长期有效 - 用
string_view作为类成员，但初始化时传入的是栈上std::string的.c_str() - 调用 C API（如
open(）后，忘了sv.data(), ...)sv本身不能保证 null-terminated，且背后内存可能随时失效
真正安全的 string_view 使用，几乎都发生在“只读、短生命周期、源头明确”的上下文中，比如解析函数参数、匹配字面量前缀、切片已存在的长字符串。
最容易被忽略的一点：没有运行时检查。悬垂 string_view 不会抛异常、不触发断言、甚至不一定立刻 crash——它可能在几万次调用后才暴露，而且只在特定内存布局下出问题。
