std::string_view 参数应按值传递；传 "hello" 安全，但传 std::string 或 s1 + s2 等临时对象易致悬垂指针；它不保证空终止、无 utf-8 长度缓存，调 c 函数或需额外处理。
用 std::string_view 作函数参数，确实能避免构造临时 std::string 对象的开销，但前提是调用方传入的是“已存在的字符串数据”，而不是靠隐式转换生成的临时对象——后者反而会引入更隐蔽的生命周期问题。
为什么传 "hello" 或 std::string 都可能出问题？
字符串字面量（如 "hello"）转 std::string_view 是零成本的，因为 string_view 只存指针和长度；但 std::string 对象传入时，编译器会调用 string_view 的构造函数，该构造函数接受 const std::string&，内部取 s.data() 和 s.size() —— 这本身不复制，但隐患在别处：
- 如果函数把
string_view存起来（比如塞进容器、返回给上层、或跨异步边界使用），而原std::string已析构，string_view就悬垂了 - 如果传入的是表达式结果，比如
func(s1 + s2)，那s1 + s2生成的临时std::string在完整表达式结尾就销毁，string_view立刻失效
string_view 参数该不该加 const&？
不该。直接写 std::string_view sv 就行。因为 string_view 本身是轻量值类型（通常仅 16 字节），拷贝成本极低，且按值传递语义清晰：函数只承诺读取当前视图范围内的数据，不延长任何生命周期。
- 加
const std::string_view&不带来性能收益，反而可能误导调用者以为要避免拷贝 - 按值传递还能让编译器更好优化（例如 RVO 或寄存器传参），实测在多数现代编译器下无差别
- 唯一例外是函数内频繁访问
sv.data()且担心指针重加载——这种场景极少，优先保证语义正确性
哪些场景下 string_view 反而更慢或更危险？
当函数内部需要多次以 O(1) 方式获取字符数、或需要空终止符（c_str()）时，string_view 不仅没优势，还可能触发额外检查或迫使你手动补 \0：
-
sv.length()是 O(1)，但sv.data()不保证以\0结尾，调 C 函数前必须自己处理（比如std::string(sv).c_str()就又构造了临时对象） - 需要计算 UTF-8 字符个数？
string_view不提供，得遍历，此时和const std::string&没区别，还少了.size()缓存保障 - 调试时打印：直接
std::cout 没问题，但若日志框架内部做了 <code>strlen或依赖 null 终止，就会越界或卡死
最常被忽略的一点：不是所有“看起来像字符串”的东西都适合喂给 string_view。比如 std::vector<char></char>、C 风格缓冲区（未保证 null 终止）、或自定义内存池中的字符串块——它们可能没有标准的 data()/size() 接口，强行转 string_view 容易漏掉边界检查。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
