std::string_view 高效但要求调用方严格保证生命周期，它不拷贝数据、仅含指针和长度、构造轻量且零开销，而 const std::string& 可能隐式构造临时对象引发堆分配。
std::string_view 不拷贝数据，const std::string& 仍可能触发隐式转换
核心差异不在“引用”本身，而在接口契约：std::string_view 明确承诺只读、不拥有、不管理生命周期；而 const std::string& 虽然也是只读引用，但调用方仍可能传入临时 std::string 对象——此时会触发隐式构造（比如从 const char* 构造），产生一次堆分配和复制。
常见错误现象：函数参数写成 void f(const std::string& s)，却传入字面量 "hello" 或 std::string_view，编译器会悄悄生成临时 std::string，开销藏得深。
-
std::string_view构造几乎总是noexcept且constexpr，仅存两个字段：const char*和size_t -
const std::string&的绑定本身无开销，但若实参是 C 字符串或std::string_view，就可能触发隐式转换构造 - 某些标准库实现中，
std::string的小字符串优化（SSO）虽避免堆分配，但仍有内部状态初始化开销（如置零、设长度、设容量）
string_view 避免了 std::string 的内部状态冗余
std::string 是完整容器，哪怕只读使用，它也携带容量（capacity()）、分配器、引用计数（在 COW 实现中）或 SSO 缓冲区等元信息；std::string_view 则只有两个成员：ptr_ 和 len_，大小通常为 16 字节（64 位平台），无构造/析构逻辑。
这直接影响缓存友好性与寄存器压力：
立即学习“C++免费学习笔记（深入）”；
- 传参时，
std::string_view可完全放入两个通用寄存器（如rdi,rsi），而std::string通常需传地址（指针 + 隐式间接访问） - 函数内联后，
string_view的data()和size()常被直接提升为常量或寄存器值；std::string的对应访问需多次内存加载（如先读_M_dataplus._M_p，再读_M_string_length） - 部分 STL 算法（如
std::search）对string_view有特化路径，跳过std::string的迭代器适配层
const char* 也能零拷贝，为什么还要 string_view？
const char* 确实最轻量，但它不带长度——每次需要 strlen() 或遍历找 '\0'，O(n) 开销不可控；而 std::string_view 在构造时就已知长度，所有操作（substr, find, 比较）都可基于长度做边界检查与快速跳转。
典型场景对比：
void process(const char* s) {
size_t len = std::strlen(s); // 每次都扫一遍！
// ...
}
<p>void process(std::string_view s) {
size_t len = s.size(); // 直接取字段，no cost
// ...
}- 字面量
"abc"传给string_view：编译期推导长度，无运行时开销 - 子串切片（如
s.substr(5, 10)）：string_view仅更新指针和长度，std::string需分配+复制 -
string_view支持empty(),front(),back()等安全接口，const char*需手动判空防崩溃
容易被忽略的陷阱：生命周期必须由调用方严格保证
std::string_view 高效的前提是——它不管理内存。一旦它指向的原始数据（如局部 std::string、栈上数组、临时对象）提前销毁，string_view 就变成悬垂视图，行为未定义。
这是比 const std::string& 更严苛的要求：
- 绝不能返回局部
std::string的string_view：return str.substr(0, 3);→ 错误！ - 接收
string_view的函数若需长期持有（如缓存、异步任务），必须明确拷贝为std::string - 与
std::string成员混用时要小心：类中存std::string_view成员，但其引用的std::string在外部被移动或析构，即失效
真正高效的代价，是把生命周期责任清晰地推给了程序员——这点比任何性能数字都关键。
