std::span 通过不拥有数据、无动态分配、编译期确定指针与长度来避免运行时开销；其 constexpr 构造函数内联后通常仅生成两条指令，汇编与 raw pointer + size_t 完全一致。
std::span 是怎么避免运行时开销的？
它不拥有数据，也不做动态内存分配，所有信息（指针 + 长度）都在编译期可确定时直接内联进调用点。构造函数是 constexpr、无分支、无函数调用，生成的汇编通常就两条指令：传地址、传长度。
常见误用是传入临时容器（如 std::vector），这时 std::span 会绑定到已销毁的内存——这不是开销问题，而是悬垂指针，属于生命周期误用，和“零开销”无关。
为什么 std::span 和 std::span 的行为差异很大？
带静态长度的 std::span 在编译期就知道大小，能启用更多优化：比如循环展开、边界检查完全消除、甚至被整个内联掉；而动态长度的 std::span 虽仍无运行时分配，但长度必须从参数读取，部分边界检查（如 subspan）无法在编译期裁剪。
-
std::span的size()直接返回常量4，无访存、无指令 -
std::span的size()返回成员变量，需一次加载（但仍是纯 load，无函数调用） - 使用
std::span时，若下标越界（如s[5]），某些编译器能在编译期报错（配合operator[]的constexpr实现）
视图语义如何影响你写代码？
“视图”意味着它不延长所指对象的生命周期，也不隐含所有权转移。你必须确保 span 存活期间，底层数组/容器依然有效。这和 std::string_view 一样，是契约而非机制。
立即学习“C++免费学习笔记（深入）”；
典型陷阱：
- 返回局部数组的
std::span：auto f() { int a[3] = {}; return std::span(a); }→ 悬垂 - 绑定到临时
std::vector的 data：std::span(v.data(), v.size())，但v是临时量 → 同样悬垂 - 跨线程传递
std::span时，没同步底层容器的生命周期管理 → 数据竞争或提前析构
和 raw pointer + size_t 相比，真的没额外成本？
在开启优化（-O2 或更高）时，绝大多数场景下，std::span 生成的机器码和手写的 T* + size_t 完全一致。区别只在类型安全和接口表达力上。
验证方法很简单：写两个函数，一个用 std::span，一个用 int* + size_t，编译后用 objdump -d 或 Compiler Explorer 对比汇编。你会发现关键路径上没有多出任何指令——除非你显式调用了 empty() 或 front() 这类带断言的成员函数（debug 模式下可能插入 assert）。
constexpr auto sum_span(std::spans) { int sum = 0; for (int x : s) sum += x; return sum; } constexpr auto sum_raw(const int* p, size_t n) { int sum = 0; for (size_t i = 0; i < n; ++i) sum += p[i]; return sum; }
这两个函数在 Clang 15 + -O2 下生成的汇编核心循环几乎一模一样。真正容易被忽略的，不是性能，而是你是否真理解了「视图」二字背后的责任：谁管内存，谁管生命周期，谁负责同步。这些没法靠编译器优化掉。
