string_view绑定局部std::string立即失效，因局部string为栈对象，函数返回即析构，其缓冲区内存被释放；而string_view仅保存指针和长度，不管理内存，导致视图悬空、访问未定义行为。
string_view 绑定到局部 std::string 为什么立即失效
因为 std::string 是栈对象，函数返回时自动析构，其内部字符缓冲区随即释放。而 std::string_view 只存了指向该缓冲区的 const char* 和长度，不参与内存管理——视图还在，但“看”的那块内存已经作废。
常见错误写法：
std::string_view get_path() {
std::string temp = "/home/user/file.txt";
return temp; // ❌ temp 析构后，返回的 view 悬空
}
- 即使加
std::string_view(temp)显式构造，也无法延长temp生命周期 - 编译器通常不会报错，运行时可能偶尔正常、偶尔崩溃或输出乱码
- 这种问题在调试模式下更难复现，Release 下更容易暴露
作为函数参数传入时为什么安全
调用方负责保证实参生命周期覆盖整个函数执行期，std::string_view 在函数体内只读、不逃逸，用完即弃。
典型安全用法：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
void log_message(std::string_view msg) {
std::cout << "[LOG] " << msg << "\n"; // ✅ 安全：msg 仅在函数内使用
}
std::string full_log = "Connection timeout";
log_message(full_log); // ✅ 绑定到命名变量，生命周期明确
log_message("retry later"); // ✅ 字面量，静态存储期
- 不要在函数内把入参
std::string_view存进类成员或全局容器 - 避免在 lambda 中隐式捕获
std::string_view并逃逸出作用域 - 若需长期持有，必须复制为
std::string或确保源数据由智能指针管理
返回 string_view 的 3 种安全姿势
不能返回指向局部对象的视图，但可以返回指向**静态/全局/堆上长期存活**数据的视图。
- ✅ 返回字面量：
return "OK";—— 字符串字面量生命周期是程序级 - ✅ 返回静态
std::string引用：static std::string s = "cached"; return s; - ✅ 返回外部传入并显式延长生命周期的数据，例如用
std::shared_ptr<std::string>管理底层字符串，再构造std::string_view（注意：view 本身仍不持有所有权，只是借用了 shared_ptr 保护的内存）
关键点：所有安全返回的前提，是让视图所指的内存地址在调用方使用期间始终有效——不是靠 string_view 自己“撑住”，而是靠外部资源管理策略兜底。
容器里存 string_view 要格外当心什么
容器（如 std::vector<std::string_view>）本身不管理数据生命周期，它只存一堆“指针+长度”。一旦原始字符串被移动、重分配、析构，所有对应 view 全部悬空。
- ❌ 不要往容器里 push_back 来自局部
std::string的 view - ❌ 避免对
std::vector<char>或std::string的.data()取 view 后长期存放——除非你能 100% 控制该容器不 resize、不 move、不析构 - ✅ 若必须缓存视图，优先考虑用
std::vector<std::string>，或者用std::string_view+ 外部std::shared_ptr<std::string>组合，并在容器外统一维护引用计数
最容易被忽略的是：即使你没显式调用 clear() 或 resize()，C++ 标准库容器在扩容时会重新分配内存并移动元素——这会导致原 std::string 内部缓冲地址改变，所有依赖旧地址的 string_view 瞬间失效。
