用 std::string_view 替代 const std::string& 可避免拷贝，但要求源字符串生命周期覆盖 string_view 使用期；它不拥有数据，易因源销毁而悬空，且不适用于需修改、长期持有、C 接口或短生命周期栈数组场景。
直接结论：用 std::string_view 替代 const std::string& 作函数参数，就能在绝大多数只读场景下彻底避免字符串拷贝——但前提是源字符串生命周期必须覆盖 string_view 的使用期。
为什么传 const std::string& 还是会拷贝？
常见误解是“加了 const& 就不拷贝”，其实问题出在调用侧：
- 当你写
parse("hello")，而parse原型是void parse(const std::string&)，编译器必须构造一个临时std::string对象，触发堆分配 + 拷贝； - 如果
parse改成void parse(std::string_view)，字面量"hello"会被隐式转换为std::string_view，仅存指针和长度，零开销； - 同理，传
std::string对象时，std::string_view构造只是读取其.data()和.size()，不碰底层缓冲区。
std::string_view 哪些操作会意外失效？
它本身不拷贝，但极易因源数据销毁而悬空。关键风险点：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 从局部
std::string返回string_view：std::string_view bad() { std::string s = "hi"; return s; }——s析构后，返回的string_view指向已释放内存； - 绑定到被移动过的
std::string：std::string s = "long"; auto sv = std::string_view(s); std::string t = std::move(s);—— 若s被 move 导致内部缓冲重分配（如小字符串优化失效），sv可能失效； - 用
std::string::data()构造后，原string执行resize()、clear()或任何可能重分配的操作，sv立即失效； -
substr()返回的新string_view仍共享原始内存，不是独立副本——这点常被误认为“安全切片”，实则没解决生命周期问题。
什么时候不能用 std::string_view？
它不是万能替代品，以下情况必须退回到 std::string：
立即学习“C++免费学习笔记（深入）”；
- 需要修改内容：比如转小写、拼接、追加 ——
string_view是只读的，连operator[]都是const； - 需要长期持有：比如存进
std::vector<:string_view></:string_view>并跨函数使用，必须确保所有源字符串活得比容器久，否则就是悬空； - 需要以
\0结尾的 C 接口：虽然string_view不保证结尾有\0，传给printf("%s", sv.data())是未定义行为； - 源是栈上字符数组且作用域窄：例如
char buf[64]; strcpy(buf, "test"); std::string_view sv(buf);—— 若buf是函数局部变量，离开作用域就危险。
真正难的不是怎么用，而是判断“谁负责活多久”。std::string_view 把生命周期责任完全交给使用者，不提醒、不检查、不兜底——你得自己画清楚数据所有权图，否则调试时看到的多半是随机崩溃或脏内存输出。
