std::span比裸指针更安全，因其将指针与长度封装为单一类型，提供size()、at(i)等内置边界检查接口，避免因遗漏长度参数导致的越界访问。
std::span 为什么比裸指针更安全
裸指针 int* 只存地址，不带长度信息，调用方必须额外传 size_t，稍有疏忽就导致越界或循环条件错误。而 std::span<int></int> 把指针 + 长度打包成一个类型，size()、data()、at(i) 等接口天然绑定长度，边界检查可直接启用。
常见错误现象：
- 传
int* p进函数，但忘记传size，函数内部用p[10]直接 UB -
std::vector::data()返回的指针被误当成无限长数组使用 - 调试时无法从指针变量看出它“本该管几个元素”
std::span 构造时对源数据的约束
std::span 不拥有数据，只引用；所以构造时必须确保源内存生命周期 ≥ span 生命周期。这点和裸指针一样危险，但语义更明确——你一眼就知道这是个“视图”，不是容器。
支持的构造方式包括：
立即学习“C++免费学习笔记（深入）”；
-
std::span<int> s(arr, 5)</int>：C 数组 + 显式长度 -
std::span<int> s(vec)</int>：从std::vector<int></int>构造（自动推导长度） -
std::span<int> s(ptr, len)</int>：裸指针 + 长度（仍需你保证ptr有效且至少len个元素） -
std::span<const char> s(str.data(), str.size())</const>：从std::string构造只读视图
不支持直接从 std::unique_ptr<int></int> 构造（除非你显式取 .get() + 长度），因为 unique_ptr 本身不暴露长度。
编译期长度（static extent）带来的实际影响
模板第二个参数 std::size_t Extent 若为具体数值（如 std::span<int></int>），表示编译期已知长度。这不只是类型标记，它会影响：
- 函数重载区分：
void f(std::span<int>)</int>和void f(std::span<int>)</int>是不同签名 - 数组字面量推导：
int a[] = {1,2,3}; auto s = std::span(a);推出std::span<int></int>，而非动态长度 - 某些优化场景下，编译器可内联
size()为常量，避免运行时读取成员
但注意：std::span<int></int> 不能接受 std::vector<int></int> 构造（因为 vector 长度运行时才确定），会编译失败。
性能与 ABI 兼容性上几乎没代价
std::span 对象本身只有两个字段：T* 和 size_t，大小和裸指针 + 一个整数完全一致，传参是纯值传递（无拷贝开销），也不触发任何构造/析构逻辑。
容易踩的坑：
- 误以为
std::span能延长底层数据生命周期——它不会，std::span离开作用域，不阻止原std::vector或栈数组被销毁 - 在返回局部数组的
std::span时没意识到悬垂风险：return std::span(arr);是严重错误 - 把
std::span<const t></const>当作const std::span<t></t>使用——前者允许修改 span 对象本身（比如调用first()），后者才禁止修改内容
真正复杂的地方在于生命周期管理责任划分：谁负责确保数据活着？答案永远是“调用方”或“数据所有者”，std::span 本身不参与，也不提示你忘了这事。
