std::string_view能避免拷贝因其仅存储const char*和size_t，不拥有内存、无分配开销；常见错误是绑定已析构的局部string或临时对象导致悬空指针。
std::string_view 为什么能避免拷贝
因为 std::string_view 只存两个字段：指向字符的 const char* 和长度 size_t，不拥有内存，也不做任何分配。只要原始字符串生命周期长于 string_view，它就纯粹是“看一眼”，零构造开销。
常见错误现象：string_view 指向局部 std::string 或字面量临时对象，函数返回后指针悬空，读到垃圾值或崩溃。比如：
std::string_view bad() {
std::string s = "hello";
return s; // ❌ s 析构了，view 指向已释放内存
}
- 只对静态存储期字符串（如字面量
"abc"）、长期存活的std::string成员、或明确保证生命周期的缓冲区使用string_view - 传参时优先用
const std::string&还是std::string_view？如果函数内部只读且不需.c_str()等兼容接口，string_view更轻；但如果要调用std::regex或 C API，仍得转std::string或用c_str() - 注意：字面量自动转
string_view是安全的（编译期确定生命周期），但std::to_string(x)返回的临时string不行
函数参数用 string_view 替代 const string& 的实际效果
当函数只读取内容（比如解析、比较、查找子串），用 std::string_view 替代 const std::string& 能省掉一次隐式构造——尤其在重载多、模板推导频繁的场景下，避免无谓的 std::string 构造/析构。
示例对比：
立即学习“C++免费学习笔记（深入）”；
void process(const std::string& s); // 调用 "hello" 会构造临时 string void process(std::string_view s); // 调用 "hello" 直接绑定，无构造
- 对
std::string对象传参：两者性能几乎一致（都是引用语义） - 对 C 风格字符串（
const char*）或字面量：string_view避免了计算长度（strlen）和构造，优势明显 - 兼容性代价：不能直接传给需要
std::string的旧接口，得显式调用.data()+.size()或构造临时std::string
string_view 的 size() 和 length() 有区别吗
没有区别。size() 和 length() 是完全等价的，都返回内部存储的长度值，时间复杂度 O(1)。C++ 标准明确要求二者行为一致，只是为了与 std::string 保持接口习惯而保留双名。
容易踩的坑：
- 误以为
string_view会自动以'\0'结尾——它不会。data()返回的指针不保证后面有结束符，拿去当 C 字符串用（比如传给printf("%s", sv.data())）是未定义行为 -
empty()安全，但sv.data()[sv.size()]不一定为'\0'，别依赖 - 用
compare()做字典序比较没问题；但用==比较两个string_view，本质还是逐字节比，不是地址比较
什么时候不该用 string_view
当你需要所有权、修改内容、或依赖空终止时，string_view 就不合适。它不是万能替代品，而是“只读快照”的专用工具。
- 要拼接、追加、替换——必须用
std::string，string_view没有这些能力 - 要传给 C API 且该 API 会写入缓冲区（比如
snprintf目标），不能用string_view::data()，那是只读的 - 从网络或文件读入数据，缓冲区生命周期由外部管理但不确定是否长于 view——宁可拷一份
std::string，也别赌生命周期 - 调试时打印
string_view内容，别直接std::cout （部分老标准库不支持），用 <code>std::cout 或 <code>sv.data()+sv.size()
最常被忽略的一点：string_view 的“零拷贝”收益，完全建立在你对数据生命周期有清晰掌控的基础上。一旦失控，性能没提升，bug 先爆炸。
