该用std::string_view而非std::string时：仅需只读访问、不修改内容，且源字符串生命周期明确长于string_view；它仅持指针和长度，避免拷贝与内存分配，适用于函数参数、日志解析、前缀匹配等场景，但禁用于修改、长期存储或指向临时对象。
什么时候该用 std::string_view 而不是 std::string
当你只读字符串、不修改内容，且明确知道源字符串生命周期长于 string_view 对象时，就该用 std::string_view。它本质是轻量级的“字符串切片”，只存指针和长度，不管理内存。
常见场景包括：函数参数接收字符串（避免传 const std::string& 导致隐式构造）、解析固定格式日志、匹配字面量前缀、拼接前做长度预判。
反例：把局部 std::string 的 c_str() 传给 string_view 并返回——局部对象一销毁，string_view 就悬空。
string_view 传参时为什么比 const std::string& 更安全高效
传 const std::string& 看似无拷贝，但调用方若传的是 C 风格字符串字面量（如 "hello"），编译器会隐式构造一个临时 std::string，再绑定引用——这就有一次堆分配和拷贝。
而 std::string_view 可直接从字面量、std::string、C 字符串构造，全程零分配：
void log_message(std::string_view msg); // ✅ 接收所有类型
log_message("error"); // 直接构造，无 string 临时对象
log_message(std::string("warn")); // 构造 view，不拷贝底层数据
log_message(some_string); // 仅记录指针+size
注意：string_view 不保证以 <p>注意：<code>string_view 不保证以 \0 结尾，所以不能直接传给 C 函数（如 printf）；需显式转成 c_str() 时，必须确保源字符串以 \0 结尾，否则行为未定义。
printf）；需显式转成 c_str() 时，必须确保源字符串以 <p>注意：<code>string_view 不保证以 \0 结尾，所以不能直接传给 C 函数（如 printf）；需显式转成 c_str() 时，必须确保源字符串以 \0 结尾，否则行为未定义。 结尾，否则行为未定义。
哪些操作会意外触发拷贝或失效
string_view 是非拥有型视图，所有操作都不改变源数据，但部分成员函数可能依赖源字符串仍有效：
-
data()和begin()返回的指针，一旦源字符串被移动、销毁或重分配（如std::string的resize()或clear()），立即失效 -
copy()不拷贝源数据，但会把内容复制到你提供的缓冲区里——这是你主动申请的拷贝，不是string_view自身行为 -
substr()返回新string_view，仍指向原内存，只要原字符串活着就安全；但若原字符串是临时std::string，比如func(std::string("tmp").substr(0,2))，则危险 - 比较操作（
==、compare()）只比内容，不关心是否以\0结尾，但若源字符串中间含\0，string_view仍会把后续字符纳入比较——这点和 C 字符串语义不同
跨函数边界使用 string_view 的生命周期陷阱
最易忽略的一点：函数返回 string_view 时，绝不能指向局部变量或临时对象。
错误写法：
std::string_view get_default() {
std::string s = "default";
return s; // ❌ s 在函数结束时销毁，返回的 view 悬空
}
正确做法：
- 返回字面量：
return "default";（静态存储期，安全） - 返回类成员
std::string的string_view，前提是调用者保证对象生命周期足够长 - 若必须动态生成，改用
std::string返回——别为了“避免拷贝”牺牲正确性
调试时可开启 -D_GLIBCXX_DEBUG（GCC）或使用 AddressSanitizer，它们能捕获部分悬空访问，但无法覆盖所有情况。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
