std::string_view仅当所指字符串生命周期严格长于其自身时才能真正避免拷贝且安全；否则将导致悬垂指针和未定义行为，而非单纯性能问题。
std::string_view 什么时候能真正避免拷贝？
只有当它指向的原始字符串生命周期严格长于 string_view 对象本身时，才安全且零拷贝。否则就是悬垂指针——不是性能问题，是未定义行为。
常见错误现象：std::string_view sv = std::to_string(42); —— 这里 std::to_string 返回临时 std::string，构造完 sv 就立刻析构，sv.data() 随即失效。
- 安全场景：传参给只读函数（如
void log(std::string_view msg)），调用方传入字面量、全局std::string或栈上已存在的std::string - 不安全场景：用局部
std::string构造string_view后返回，或存入容器长期持有 - 参数差异：
const std::string&允许隐式转成std::string_view，但反过来不行；函数签名用string_view更泛化，也更轻量
为什么不能直接把 string_view 当 string 用？
std::string_view 是只读视图，不拥有数据，也不提供内存管理能力。试图对它调用 append、resize 或取非 const 迭代器，编译就报错。
使用场景：适合做“输入”——解析、查找、比较、切片；不适合做“输出”或中间拼接。
立即学习“C++免费学习笔记（深入）”；
- 想拼接？必须显式转成
std::string：std::string{sv1} + std::string{sv2}，这里就有两次拷贝 - 想修改内容？只能操作原始字符串，
string_view无法帮你改 - 性能影响：用
string_view替换const std::string&参数，函数调用开销从 8 字节（指针）降到 16 字节（指针+长度），但无运行时额外成本
substr 和 remove_prefix 的坑在哪？
这两个操作都返回新 string_view，但底层仍指向原内存——这本是优势，可一旦原始字符串被释放或重排，所有派生的 string_view 全部失效。
错误示例：
std::string s = "hello world";
auto sv = std::string_view{s};
auto word = sv.substr(0, 5); // ok
s.clear(); // 原内存已释放
// 此时 word.data() 指向已释放内存
-
substr不检查越界，越界时行为未定义（不是抛异常） -
remove_prefix(n)和remove_suffix(n)修改的是当前对象，不是返回副本，注意别误以为是 immutable - 调试时很难发现这类 bug，因为悬垂访问有时“恰好”还能读出旧值，直到内存被复用才崩
和 C 风格字符串混用要注意什么？
string_view 不保证以 '\0' 结尾，而 strlen、printf("%s", ...) 等 C 函数依赖结尾空字符。直接传 sv.data() 可能导致越界读。
使用场景：需要调用 C API 时，必须确保安全。
- 如果确定源字符串以
'\0'结尾（比如来自std::string或字面量），可用sv.data()，但别假设它永远安全 - 不确定时，显式复制到带结尾的缓冲区：
std::string tmp{sv}; puts(tmp.c_str()); - 兼容性影响：在 Windows API（如
CreateFileA）中传sv.data()而不验证结尾，可能触发路径截断或权限错误
string_view，而是谁在什么时候释放那块它正看着的内存。 
