std::span 构造时必须确保所引用数据的生命周期严格长于 span 实例，因其不拥有数据、仅为内存视图；临时指针、析构后的 vector、局部数组等均会导致悬空视图和未定义行为。
std::span 构造时必须确保生命周期足够长
std::span 不拥有数据，它只是对已有内存的“视图”。如果你用它包装一个临时指针（比如 C API 返回的栈分配数组、或局部 std::vector 的 data() 但 vector 已析构），程序会立刻进入未定义行为——读写可能崩溃，也可能看似正常却悄悄出错。
常见错误场景：std::vector<int> v = {1,2,3}; auto s = std::span(v.data(), v.size()); 看似没问题，但如果 v 在 s 使用前被移动或销毁，s 就成了悬空视图。
- 正确做法：确保原始数据的生存期严格长于
std::span实例；C API 的缓冲区若由调用方分配（如malloc或静态数组），需自行管理释放时机 - 若 C API 返回的是只读缓冲区（如
const char*+size_t len），优先用std::span<const T>，避免意外修改 - 不要用
std::span包装函数返回的局部数组地址（如return arr;中的arr）
从 void* + size_t 转换需显式 reinterpret_cast，且必须保证类型对齐与大小一致
C 风格 API 常用 void* 和 size_t 传递数据，而 std::span<T> 要求元素类型明确。直接构造会编译失败，必须手动转换指针类型。
例如某 C 函数签名：int read_data(void** out_buf, size_t* out_size);，返回的是 uint8_t 字节流：
立即学习“C++免费学习笔记（深入）”；
void* raw_ptr; size_t raw_size; read_data(&raw_ptr, &raw_size); auto bytes = std::span<std::byte>(reinterpret_cast<std::byte*>(raw_ptr), raw_size);
- 用
std::byte是最安全的起点；若已知是int32_t数组，且确认字节长度整除sizeof(int32_t)，才可转为std::span<int32_t> - 切忌用
reinterpret_cast<T*>绕过对齐检查：如果原始void*地址未按T对齐（如int*指向奇数地址），访问会触发硬件异常（尤其在 ARM 或严格对齐平台） -
raw_size必须是sizeof(T)的整数倍，否则std::span的size()会向下取整，丢失末尾字节
传给 C++ 算法时注意 span 的 const 正确性
很多标准算法（如 std::sort、std::find）接受迭代器范围，std::span 可隐式转为 begin()/end()，但类型匹配容易出错。
比如你有一个 std::span<const int>，试图传给需要非 const 迭代器的 std::sort，编译直接失败——不是“不能排序”，而是你声明了只读视图。
- 若算法要修改内容，构造
std::span<T>（非 const 版本），并确认底层内存确实可写 - 使用
std::as_writable_bytes()获取可写字节视图时，仅适用于 POD 类型，且不改变原 span 的 const 属性 - 对
std::span<const T>调用.data()得到的是const T*，传给期望T*的 C 函数会编译报错，此时需确认该 C 函数是否真会写入；若不会，应改用const_cast（谨慎！）或要求 C API 提供 const 版本
跨边界传递 span 时，避免隐式拷贝和裸指针泄漏
std::span 是轻量值类型（通常两个指针大小），传值开销小，但容易误以为它“带所有权”。一旦你把 std::span 传给另一个模块，并在那里保存其 data() 和 size()，就等于退化回裸指针——生命周期责任丢失。
- 函数参数尽量用
std::span<const T>或std::span<T>值传递，而非存储T*+size_t - 类成员中缓存
std::span是危险的，除非你能 100% 保证所引用的数据生命周期覆盖整个对象生命周期 - 不要通过
std::span::data()向 C API “返还”指针，除非你知道 C API 不会持有该指针——否则后续std::span析构后，C API 仍可能访问已失效内存
最难的不是怎么写，是怎么让所有协作者都清楚：span 不是智能指针，它不延长生命，也不限制访问——它只是一张地图，画得再准，也救不了走错路的人。
