问题的历史
std::span 在 C++20 中的引入标志着 C++ 核心指导原则中的 gsl::span 这一长期习惯的标准化。其设计目标是提供对连续序列的零开销抽象，替代 API 中的原始指针-长度对。委员会明确拒绝了拥有语义，以维持与原始指针匹配的性能特征，符合 std::string_view 的理念。这个决定源于与 C 风格数组和遗留代码的互操作性的需求，而不施加分配开销。因此，std::span 继承了非拥有视图的基本限制，尤其是生命周期管理方面。
问题
当 std::span 从一个 prvalue 容器，诸如返回 std::vector<T> 的工厂函数的返回值，进行初始化时，隐患就出现了。在这种情况下，临时向量在完整表达式结束时被销毁，而 std::span 保留对向量已被释放的堆存储的内部指针。由于 std::span 是一个简单可复制的类型，在编译器的生命周期分析中与原始指针对无法区分，因此语言没有针对该悬空引用提供强制诊断。C++20 标准规定 std::span 建模为借用范围，但这个概念仅影响基于范围的循环和算法，而不影响基础存储的基本生命周期规则。这造成了一种虚假的安全感，因为语法看起来像是安全容器的使用，同时却隐含着类似于返回指向局部变量的指针的不确定行为。
解决方案
缓解措施需要严格遵守生命周期延长原则并利用静态分析。开发者必须确保拥有容器的生命周期比任何引用它的 std::span 更长，理想情况下在创建视图之前将容器声明为命名变量。使用像 Clang-Tidy 这样的工具，配合 cppcoreguidelines-pro-bounds-lifetime 检查，可以捕捉来自临时对象的初始化。对于 API 设计，函数应当接受 lvalue 参数的 std::span 通过值传递，但要记录前置条件，要求调用者保持存储的有效性。当需要拥有语义时，优先使用 std::unique_ptr<T[]> 或 std::vector 本身，仅在调用者保证生命周期时使用 std::span 作为函数参数传递。
#include <span> #include <vector> #include <iostream> std::vector<int> generate_buffer() { return std::vector<int>(1024, 42); // 临时向量 } void process(std::span<int> data) { // 如果数据悬空则导致未定义行为 std::cout << data.front() << '\n'; } int main() { // 悬空：临时在完整表达式后被销毁 process(generate_buffer()); // 安全：容器的生命周期长于 span auto buffer = generate_buffer(); std::span<int> safe_view(buffer); process(safe_view); }
在一个实时音频处理引擎中，一个混音线程接收来自解码器包装的 PCM 数据，它通过值返回 std::vector<float>。混音器立即构造了一个 std::span<float> 以传递给 DSP 算法，旨在避免每次回调复制千字节的音频数据。在质量保证过程中，当垃圾收集器（在桥接的 C# 环境中）触发时，应用程序不时崩溃并出现音频失真，这恰好与 C++ 缓冲区访问同时发生。
工程团队考虑了三种不同的方法来解决生命周期不匹配。
第一种方法涉及将向量数据复制到一个由混音线程拥有的预分配循环缓冲区。这保证了 std::span 始终指向有效内存，完全消除了悬空引用。然而，memcpy 操作每通道消耗了大约 5 微秒，这超过了 1 毫秒的硬实时截止期限，使得该解决方案不适合低延迟的要求。
第二种方法建议将解码器包装更改为填充一个引用参数 std::vector<float>&，而不是按值返回。这将使向量的生命周期延长到调用者的作用域。虽然这消除了临时对象，但破坏了 API 的不可变性保证，并迫使调用者管理向量的容量，从而导致每个调用点的繁琐对象池逻辑并降低代码的清晰度。
第三种方法利用了一个自定义的 AudioBufferHandle 类，它持有一个 std::shared_ptr<std::vector<float>> 并隐式转换为 std::span<float>。混音器接受该句柄，提取 span 以进行即时处理，句柄的析构函数在 DSP 完成之前保持向量的存活。由于它在确保通过 RAII 进行生命周期安全的同时保持了零复制要求，这种方法被选中，而引用计数的开销与音频处理负载相比微不足道。
结果是一个没有崩溃的音频管道，在高负载下通过 ASAN（地址卫生检查）和 TSAN（线程卫生检查）检查，尽管它需要细致的文档来防止开发者在句柄的生命周期之外存储 span。
为什么用带花括号的初始化列表初始化 std::span 如 std::span<int> s = {1, 2, 3}; 会导致悬空指针，而 std::vector<int> v = {1, 2, 3}; 保持有效无期限？
带花括号的初始化列表创建了一个临时的 std::initializer_list<int>，它在概念上持有指向自动存储持续时间的整数临时数组的指针。当 std::span 通过其推导指南绑定到此初始化列表时，它捕获了指向该临时数组的指针。临时数组在完整表达式结束时被销毁，导致 span 悬空。相反，std::vector 具有分配器，并将元素复制到保持有效的堆存储中，直到向量被销毁。候选人常常将初始化列表的语法与容器构造函数混淆，忘记 std::span 不执行任何分配或复制，仅充当视图。
如何 constexpr 功能的 std::span 与自动存储持续时间交互，以及为什么指向局部非静态数组的 constexpr span 从函数返回时可能导致未定义行为？
std::span 是一个字面量类型，允许 constexpr 使用，但 constexpr 仅要求初始化可以在编译时被求值；它并不改变基础数组的存储持续时间。如果一个函数定义一个局部非静态数组并返回一个 constexpr std::span，则数组具有自动存储持续时间，并在函数退出时被销毁，从而立即使 span 无效。混淆产生于候选人假设 constexpr 变量隐含地具有静态存储，或编译器防止常量表达式中的悬空情况，但 std::span 仅封装指针，指向自动变量的指针无论 constexpr 资格如何均变得无效。
什么具体限制阻止 std::span 从内部构造容器的函数安全返回，如何与面临类似但细微不同约束的 std::string_view 形成对比？
std::span 和 std::string_view 都是非拥有的视图，但 std::string_view 通常用于具有静态存储持续时间的字符串文字，掩盖了悬空问题。当一个函数在内部构造一个 std::vector 或 std::string 并试图返回一个 span/view 时，容器在函数退出时被销毁，从而使视图失效。关键区别在于 std::string_view 可以绑定到具有静态生命周期的以 null 结尾的字符串文字 (const char[])，使得像 std::string_view get() { return "literal"; } 这样的模式是安全的，而 std::span 不能以相同方式绑定到数组文字，而不创建临时数组。候选人常常忽略 std::span 比 std::string_view 更通用，且缺乏字符串文字存储的特殊情况，使得从局部容器返回 span 的所有情况无条件不安全。