std::string_view 是只读视图，非万能零拷贝方案；适用函数参数等短期只读场景，需确保源字符串生命周期长于 view；误存临时对象或跨模块传递易致悬空、UB 或 ABI 问题。
std::string_view 不是万能的零拷贝替代品，它只是对已有字符串内存的只读视图；用错场景（比如保存临时字符串的 view）会导致悬空指针和未定义行为。
什么时候该用 std::string_view 而不是 const std::string&
核心判断依据：你是否确定传入的字符串生命周期一定长于 string_view 的使用周期？
- 适合：
string_view用于函数参数（尤其是只读处理），且调用方能保证原始字符串（如局部std::string、字面量、静态缓存）在函数返回前不销毁 - 不适合：把
"hello"或std::string{"world"}的string_view存进类成员或返回给调用方——前者字面量没问题，后者临时对象一退出作用域就析构，view 立刻悬空 - 典型好场景：解析配置、日志格式化、URL 路径匹配、CSV 字段切分——输入通常来自长期存活的缓冲区或文件映射
string_view 构造时的常见陷阱
构造本身不复制数据，但容易因隐式转换埋雷：
- 字面量自动转
string_view安全：foo("abc")→foo(string_view{"abc", 3})，因为字面量寿命是整个程序期 -
std::string隐式转string_view危险：foo(s)其中s是局部变量，若foo把 view 缓存起来，后续访问就是野指针 - 空指针检查无效：
string_view不保证底层data()非空；构造时传入nullptr（如string_view{nullptr, 0}）合法，但调用data()或begin()前必须自己判空 - 注意 C 风格字符串结尾：
string_view{"abc"}长度为 3，不包含末尾\0；string_view{str.c_str()}若没传长度，会按\0截断——但str中间若有\0就提前截断了
性能差异在哪？别只看“没拷贝”
减少拷贝只是表象，真正收益来自两方面：避免堆分配 + 提升 CPU 缓存局部性。
立即学习“C++免费学习笔记（深入）”；
- 传
const std::string&进函数，如果函数内部要取.c_str()或遍历字符，仍需确保字符串已以 null 结尾、可能触发小字符串优化（SSO）分支判断 -
string_view是纯值类型（通常仅两个字段：const char*+size_t），传参开销固定 16 字节（x64），无构造/析构成本 - 但注意：频繁从
string_view创建std::string（如std::string{sv}）反而更慢——这等于主动触发一次拷贝，还多了一次内存分配 - 兼容性代价：C++17 起才支持；跨 DLL 边界传递
string_view需谨慎，不同模块可能用不同 STL 实现，ABI 不保
和 std::string 混用时的关键边界
string_view 的所有操作都是只读的，且不管理内存，所以和 string 交互必须显式转换：
- 不能直接拼接：
sv1 + sv2编译不过；得写std::string{sv1} + std::string{sv2}或std::string{sv1}.append(sv2) - 查找结果是
size_t，不是迭代器；sv.find("x")返回位置索引，要用sv.substr(pos)切子串，而非sv.begin() + pos - 比较操作安全：
sv == "abc"、sv 都可用，底层是 memcmp 级别，比 <code>string::operator==少一层 length 检查开销 - 最易忽略的一点：
string_view::data()返回的指针可能不以\0结尾，传给 C 函数（如printf("%s", sv.data())）前必须确认或手动补\0，否则越界读
真正难的不是怎么用，而是每次拿到一个 string_view 时，都得下意识问一句：它背后那片内存，此刻归谁管？还能活多久？
