瞬时视图：std::string_view所有权设计中performance与type safety的权衡——为何允许静默悬空引用？

先看你贴的这段问题代码：

#include <string_view>
#include <iostream>

int main() {
    std::string_view sv = std::string("Hello") + " World"; 
    std::cout << sv << std::endl;
}

这段代码里的sv确实会在语句结束后直接悬空——临时生成的std::string在赋值完成的瞬间就销毁了，sv指向的内存直接变成无效状态，这确实是个悄无声息的坑，也难怪你会疑惑为什么标准不直接堵上这个漏洞。

咱们先拆解第一个核心问题：为什么语言设计允许std::string_view绑定到右值（临时对象），而不是直接删掉右值的构造函数？

其实根源在于std::string_view的设计初心：它就是个零开销的非拥有式视图，目标是替代const char*和const std::string&，在完全不拷贝字符串的前提下安全传递字符串数据。如果一刀切禁用了右值构造，很多合法且高效的场景就直接用不了了——比如：

// 完全安全：临时对象和视图的生命周期绑定在整个表达式内
std::cout << std::string_view(std::string("Hello") + " World") << std::endl;

这种场景下，临时字符串和视图的生命周期完全同步，整个表达式执行完毕才会销毁，完全没有问题。要是标准强行禁止右值构造，这种高效的写法就直接被判死刑了，反而把string_view的灵活性砍了一大截。

另外，C++从诞生起就死守零开销原则（Zero Overhead Principle）：你不需要的东西，就绝对不用为它付费。如果给string_view加个右值构造的限制，要么需要编译器做额外的生命周期检查（可能带来运行时开销），要么直接禁止所有右值场景——这显然违背了string_view的设计目标，毕竟它就是为了极致高效而生的。

再说说类型安全的边界问题：C++从来不是那种“保姆式”的语言，它的核心哲学是把控制权交还给开发者。std::string_view的文档已经明明白白写死了“我不拥有数据，你得自己保证我指向的对象活得比我久”。标准委员会认为，与其强行禁止所有可能出错的情况（哪怕其中很多是合法的高效场景），不如让理解语义的开发者自由发挥——毕竟开发者才最清楚自己代码里对象的生命周期。

那这是不是意味着C++17把性能放在类型安全之上，让开发者哪怕用现代抽象也要当全职内存管理者？

其实这是平衡，不是单纯的优先级倾斜。C++17确实加了很多类型安全特性（比如结构化绑定、constexpr if），但对于string_view这种核心高效抽象，委员会选择了“安全够用即可”的路线：它比原始指针安全（自带长度，不会随便越界），但又保留了原始指针的零开销——代价就是开发者需要花5分钟理解它的所有权语义。

而且，现代抽象的目的是减轻开发者的内存管理负担，而不是完全接手。string_view让你不用再手动处理const char*的长度问题，也不用为了传递字符串而频繁拷贝，但你还是要对自己的代码负责——这和C++一直以来的哲学是一致的：信任开发者，给他们足够的灵活性去写出最高效的代码，同时提供工具（比如编译器警告）帮他们提前踩坑。

最后提个实用小建议：现在主流编译器都能检测到这种悬空的string_view了，比如GCC的-Wdangling-pointer、Clang的-Wdangling-gsl，打开这些警告能帮你提前发现90%的这类问题。

备注：内容来源于stack exchange，提问作者Spook