std::string_view 能避免拷贝开销，核心在于不拥有数据、仅持指针与长度，传参返回均为16字节值传递，零构造析构；支持O(1)长度获取、嵌入'\0'字符串、直接比较，但要求调用方确保底层内存生命周期足够长。
为什么 std::string_view 能避免拷贝开销
核心优势就一条：它不拥有字符串数据，只持有一个指向已有内存的指针 + 长度。传参、返回、切片时全是 sizeof(std::string_view)（通常 16 字节）的值传递，完全绕过堆分配和字符拷贝。
比如函数接收 const std::string&，调用方传字面量 "hello" 时，编译器可能隐式构造临时 std::string；而用 std::string_view，直接绑定到字面量的静态存储区，零构造、零析构。
- 适用于所有已知生命周期长于
string_view使用范围的字符串源（如全局字面量、std::string对象本身、C 风格数组） - 不能用于保存临时字符串（如
std::string("tmp").c_str()的结果），否则string_view会悬空 - 对 C++14 项目，可用
absl::string_view或手动实现轻量 wrapper 替代
string_view 和 const char* 比有什么实际好处
const char* 没长度信息，遇到嵌入 '\0' 或需要 O(1) 获取长度时必须遍历；string_view 把长度缓存为成员，.size()、.empty()、.substr() 全是常数时间，且支持标准容器式操作（find、starts_with、compare）。
-
"abc\0def"_sv.size()返回 7，不是 3 —— 它按你显式指定或推导的长度算，不依赖'\0' -
string_view可直接和std::string、字面量比较（sv == "test"），无需先转std::string - 注意：
string_view不保证以'\0'结尾，所以不能直接传给printf或 C API 要求 null-terminated 的函数
哪些函数签名适合立刻换成 string_view
凡是只读、不修改、不延长字符串生命周期的接口，都是安全替换目标。典型包括日志函数、解析器输入、配置键名、文件路径拼接参数等。
立即学习“C++免费学习笔记（深入）”；
- 把
void log(const std::string& msg)改成void log(std::string_view msg)，既接受std::string，也接受"literal"，还接受char buf[256]加长度构造的视图 - 避免写
void process(std::string_view s1, std::string_view s2)然后内部又转回std::string—— 这样反而多一次构造，失去意义 - 若函数内部需多次访问（如循环中反复取
[i]），string_view的随机访问性能和const char*相当，但语义更清晰
容易被忽略的生命周期陷阱
最常见错误：用局部 std::string 的 c_str() 构造 string_view 并返回或长期持有。
std::string_view bad() {
std::string tmp = "hello";
return std::string_view(tmp.c_str(), tmp.size()); // ❌ tmp 析构后视图悬空
}
正确做法是确保源数据生存期覆盖整个 string_view 使用过程：
- 参数传入的
string_view，其生命周期由调用方保证，函数内可放心使用 - 若需持久化，要么复制进
std::string，要么明确文档要求调用方维持底层内存有效 - 用
std::string_view::data()获取指针时，别把它当成 C 字符串用 —— 它不一定以'\0'结尾
它的高性能是真实的，但“只读”和“不管理内存”这两个约束，必须由程序员主动兜底。
