std::string_view是轻量级只读视图，不拥有数据，仅存指针和长度；不能直接当std::string用，因其无内存管理、不可修改、不保证空终止，且生命周期依赖底层数据。
std::string_view 是什么，为什么不能直接当 std::string 用
std::string_view 不是字符串容器，而是一个轻量级的、只读的“视图”——它只存两个成员：const char* 指针和 size_t 长度，不拥有数据，也不管理内存。这意味着它零拷贝、构造开销极小，但前提是它所指向的原始字符数据生命周期必须比 string_view 本身长。
常见误用：把局部 std::string 的 c_str() 或 data() 传给 string_view 并返回，导致悬垂指针：
std::string_view bad_example() {
std::string s = "hello";
return std::string_view(s.data(), s.size()); // ❌ s 析构后 data() 失效
}
正确做法：确保底层存储长期有效（如字面量、静态变量、或由调用方保证生命周期的参数）。
如何安全地构造和传递 string_view 参数
函数参数用 std::string_view 替代 const std::string& 是 C++17 最实用的性能优化之一，尤其对高频调用接口（如解析、匹配、日志格式化）。它能同时接受字面量、std::string、C 风格数组，且无隐式转换开销。
立即学习“C++免费学习笔记（深入）”；
- 接受字面量：
"abc"→ 自动推导为std::string_view（编译期知道长度） - 接受
std::string s：func(s)→ 调用string_view(const char*, size_t)构造，不拷贝内容 - 接受 C 数组：
char buf[10] = "test"; func(buf)→ 注意数组必须以\0结尾或显式传长度，否则可能越界
推荐写法：
void process(std::string_view sv) {
if (sv.empty()) return;
// 安全访问：sv.data()[0], sv[0], sv.substr(...), sv.find("...") 等
}
哪些操作是安全的，哪些容易踩坑
string_view 支持大部分只读操作，但所有修改类接口（+=, append, resize）都不存在；它也不提供 c_str()（因为不保证以 \0 结尾）。
易错点列表：
-
sv.data()返回的指针不保证以\0结尾 → 不能直接传给 C 函数如printf("%s", sv.data())，除非你确认它来自字面量或已补\0 -
sv.substr(pos, len)不检查边界 →pos > sv.size()或len过大会导致未定义行为（不是抛异常） - 不能隐式转成
std::string→ 需显式构造：std::string(sv)（此时才发生拷贝） - 比较操作（
==,）按字典序进行，但注意大小写敏感，且不处理编码（仍是 raw bytes）
string_view 和 string 的性能差异在哪
关键差异不在“快多少”，而在“什么时候不花额外成本”。例如：
// 假设 parse_key_value 接收 key 和 value 作查找
bool parse_key_value(const std::string& k, const std::string& v); // 每次调用都可能触发小字符串优化或堆分配
bool parse_key_value(std::string_view k, std::string_view v); // 零分配，仅传两个机器字
// 调用侧：
parse_key_value("timeout", my_config.value()); // ✅ 字面量 + string → 都免拷贝
但要注意：如果函数内部需要多次拼接、修改或长期持有字符串内容，string_view 就不合适了——它只是视图，不是替代品。真正省下的不是 CPU 时间，而是避免了不必要的内存分配与释放，尤其在短字符串高频场景下（比如 HTTP header 解析、JSON key 查找），cache 局部性也更好。
最常被忽略的一点：不要为了“看起来现代”而强行把所有 const std::string& 替成 string_view，特别是当函数逻辑依赖于 std::string 的某些特性（如 capacity()、get_allocator()、或需要空终止）时，反而增加理解成本和风险。
