std::string_view传参时临时对象提前析构是因为其不拥有数据，仅存指针和长度；临时std::string或拼接结果在完整表达式结束即销毁，而string_view仍访问已释放内存，导致未定义行为。
std::string_view 传参时为什么字符串临时对象会提前析构？
因为 std::string_view 不拥有数据，只存指针和长度；传入临时 std::string 或字面量拼接结果（如 std::string{"a"} + "b"）时，临时对象在完整表达式结束就销毁，但 string_view 还在用那块内存——立刻 UB。
- 安全做法：只绑定生命周期明确的源，比如函数参数里的
const std::string&、全局/局部const char[]、或std::string对象本身（确保它活得比string_view久） - 危险写法示例：
func(std::string{"hello"}.substr(0, 3));——substr()返回新std::string，临时对象立即销毁 - 更隐蔽的坑：
func(("hello"s + " world").substr(0,5));，"hello"s是std::string字面量，整个表达式仍是临时对象
std::string_view 和 const std::string& 传参性能差多少？
对短字符串（小字符串优化启用时），两者差异极小；但对长字符串或频繁调用场景，std::string_view 省掉一次隐式构造和可能的引用计数/堆检查，实测快 10%–30%，尤其在模板函数或内联热路径中明显。
-
const std::string&仍要检查是否需要构造（哪怕只是轻量引用），而std::string_view是纯值语义，无状态、无分配、无虚函数 - 兼容性代价：C++17 起才可用；若需支持 C++14 或更低，不能直接替换，得加宏或重载
- 注意：如果函数内部需要
.data()可修改（比如传给 legacy C API 写入），string_view不行，必须用std::string或std::vector<char></char>
std::string_view::substr() 出现 out_of_range 怎么办？
substr() 不抛异常（除非你开 -D_GLIBCXX_DEBUG），但若 pos > size() 或 pos + count > size()，行为是未定义——常见表现是返回空 view 或越界读，调试器里看着像“随机截断”。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 永远先校验：
if (pos - 别依赖
substr(pos)的“自动截断”逻辑：标准只要求当pos == size()时返回空 view；pos > size()就是 UB - 替代方案：用
sv.begin() + pos配合std::min手动算范围，更可控，也避免构造新 view 的开销
从 std::string_view 构造 std::string 有哪些隐含成本？
本质是一次内存分配 + memcpy，大小就是 sv.size()。看似简单，但在高频循环或日志拼接中容易成为瓶颈，尤其当 view 指向大 buffer 的一小段时（比如解析一个 1MB JSON 中的 5 字符字段，却拷贝出新 std::string）。
立即学习“C++免费学习笔记（深入）”；
- 能避免就避免：比如只用于比较（
sv == "abc"）、查找（sv.find("x")）、或传给另一个接受string_view的函数 - 真要构造时，优先用
std::string{sv}而不是std::string{sv.data(), sv.size()}—— 前者可能触发 SSO 优化，后者强制走两参数构造，绕过部分优化路径 - 注意：
sv.data()不保证以\0结尾，所以std::string{sv.data()}是错的，会读到未知位置
最麻烦的不是语法，是生命周期判断和边界校验——这两个点没盯住，高性能就变成高崩溃率。
