std::string_view 是轻量级只读字符串视图，由 const char* 指针和 size_t 长度组成，构造不拷贝数据，切片为 o(1)；但依赖底层缓冲生命周期，悬空指针是常见错误。
std::string_view 是什么，为什么能避免拷贝
它不是字符串容器，而是一个只读的、轻量级的字符串“视图”——本质是两个成员：const char* 指针 + size_t 长度。构造时不复制数据，只记录原始内存的起始和长度，所以切片（如 substr()）开销是 O(1)，不是 O(n)。
常见错误现象：把局部 std::string 的 c_str() 传给 std::string_view，然后函数返回后视图悬空——因为底层指针指向的栈内存已销毁。
- 使用场景：函数参数（替代
const std::string&）、解析日志/协议头、拼接前的临时切片 - 不适用场景：需要修改内容、需要拥有所有权、底层缓冲生命周期不确定时
- 性能影响：构造/拷贝
std::string_view几乎零成本；但若底层字符串被移动或析构，视图立即失效
怎么安全地用 substr() 做切片而不拷贝
std::string_view::substr() 返回的仍是 std::string_view，不分配内存、不复制字节，只是调整内部指针和长度。但它依赖原视图（或其源头）的生命周期。
典型踩坑：从函数返回的临时 std::string 创建视图再切片——例如 foo().substr(0,3)，其中 foo() 返回 std::string，整个表达式里临时对象在完整表达式结束就销毁，后续使用该视图就是未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 安全做法：确保源字符串（或其
string_view）的生命周期 ≥ 所有衍生视图的生命周期 - 推荐模式：把长字符串存为 const 变量或类成员，再基于它创建多个
string_view - 示例：
const std::string data = "HTTP/1.1 200 OK"; std::string_view sv = data; std::string_view status_line = sv.substr(0, sv.find('\n')); // 安全
传参时用 string_view 替代 const string& 真的更优吗
多数情况下是的，但前提是调用方传的是字符串字面量、std::string 或其他可隐式转成 string_view 的类型（如 C 风格字符串）。编译器能直接构造视图，跳过 std::string 构造开销。
容易忽略的兼容性问题：C++17 起才支持 string_view；且它不能隐式转成 std::string，如果函数内部需要修改或存储，必须显式拷贝（如 std::string{sv}）。
- 适合做参数的函数：解析类、比较类、查找类（如
bool starts_with(std::string_view s, std::string_view prefix)） - 不适合直接替换的场景：函数要长期持有字符串、要调用只接受
std::string的第三方接口、需要空终止 C 字符串（sv.data()不保证以'\0'结尾） - 参数声明建议：
void process(std::string_view input)，而不是void process(const std::string& input)—— 前者接受字面量、string、c_str()，后者拒绝字面量（除非隐式构造临时string）
string_view 和 string 的边界在哪，什么时候必须拷贝
当你需要以下任一操作时，std::string_view 就不够用了，必须转成 std::string：
- 追加内容（
+=）、插入、删除、大小写转换等修改操作 - 传给要求 null-terminated 的 C API（如
fopen、printf），此时得用std::string{sv}.c_str()或确保源字符串本身以'\0'结尾 - 跨线程传递且无法控制源字符串生命周期（比如异步回调中保存视图）
- 需要值语义持久化：比如塞进
std::vector<:string></:string>或作为 map 的 key
一个常被忽视的细节：std::string_view 的 data() 不保证以 '\0' 结尾，哪怕它来自 std::string。所以别想当然地把它当 C 字符串用。
