std::span 构造时不检查空指针，传入 nullptr 加非零长度会导致未定义行为；subspan 切片安全且零开销，但起始位置超 size()+ 1 即 UB；迭代器无边界信息，遍历需自行防越界。
std::span 构造时传入裸指针和长度，不检查空指针
很多人以为 std::span 会像 std::vector::at() 那样做空指针防护，其实不会——它只保证后续访问不越界，但构造本身完全信任你传的参数。一旦传了 nullptr 加非零长度，后续任何操作（哪怕只是 data() 或 size()）都属于未定义行为。
常见错误现象：std::span<int>(nullptr, 10)</int> 编译通过，运行时可能立即崩溃，也可能在首次访问时崩，调试困难。
- 使用场景：封装 C API 返回的
int*+size_t，或从malloc分配的内存构造span - 实操建议：手动加断言或封装工厂函数，比如
make_span(int* p, size_t n) {assert(p || n == 0); return std::span<int>(p, n); }</int> - 注意：
std::span的默认构造函数生成的是空 span（data() == nullptr且size() == 0），这是安全的
用 span::subspan 切片比手算指针偏移更安全
直接写 ptr + offset 再传给新 std::span 容易越界，而 subspan 在编译期就知道原始 span 边界，运行时会做范围校验（取决于实现是否开启调试模式，但语义上它承诺不越界）。
性能影响：Release 模式下 subspan 是零开销抽象，只改两个成员变量；Debug 模式下部分标准库（如 MSVC 的 _ITERATOR_DEBUG_LEVEL）会检查参数合法性。
立即学习 “C++ 免费学习笔记（深入）”；
- 参数差异：
s.subspan(2, 5)表示从索引 2 开始取 5 个元素；s.subspan(2)表示从索引 2 到末尾 - 容易踩的坑：传入超出当前
size()的起始位置（如s.subspan(s.size())合法，返回空 span；但s.subspan(s.size() + 1)是未定义行为） - 示例：
auto s = std::span(arr, 10); auto tail = s.subspan(3); // 安全，tail.size() == 7
span 的迭代器不带边界信息，遍历时仍需自己防越界
std::span 的 begin()/end() 返回的是原生指针（或包装指针的迭代器），它们本身不携带长度信息。所以用 for (auto it = s.begin(); it != s.end(); ++it) 是安全的，但若写成 for (size_t i = 0; i 就会在 <code>i == s.size() 时越界。
为什么这样做：为了保持与原生数组 / 指针一致的性能模型，避免每次解引用都查表或分支判断。
- 常见错误现象：
for (size_t i = 0; i 导致访问 <code>s[s.size()]—— 这是越界，不是“末尾哨兵” - 实操建议：优先用基于范围的 for 循环（
for (auto& x : s)），或严格用i - 兼容性注意：C++20 起
std::span迭代器满足RandomAccessIterator，可放心用it + n，但依然不自动防n > s.size()
跨函数传递 span 时，别假设底层内存长期有效
std::span 不拥有数据，只借用。如果把局部数组的 span 传给异步回调、或存进类成员里，等回调执行时栈帧已销毁，data() 就悬空了。
这比裸指针更隐蔽：因为语法上没出现 & 或 new，容易误以为“span 是现代的，所以安全”。其实它只是把生命周期责任显式甩给你。
- 使用场景：函数参数接收
std::span<const t></const>是极佳实践；但返回std::span<t></t>给调用方必须确保底层内存寿命 ≥ span 寿命 - 容易踩的坑：写
return std::span(buf, len);其中buf是函数内局部数组 - 替代方案：需要延长生命周期时，改用
std::vector或std::unique_ptr管理内存，再用span视图化访问
边界检查这件事，std::span 只管“你告诉它的范围”，不管“你告诉它的范围是否真实有效”。它优化掉的是重复计算，不是责任转移。
