std::span本身不提升内存安全性，它仅封装裸指针+长度，真正安全依赖生命周期管理、边界校验和const语义正确使用；其不分配内存、不延长生命周期，仅提供零开销视图。
std::span 本身不提升内存安全性，它只是把裸指针 + 长度这个危险组合显式封装；真正安全取决于你是否管住生命周期、是否做边界校验、是否用对 const 语义。
std::span 构造前必须已有合法且存活的缓冲区
很多人写 std::span<const std::byte>{data, size}</const> 却没想清楚 data 从哪来、能活多久。它不分配内存、不读文件、不延长生命周期——只是一对指针的视图。
- 错误做法：局部
char buf[4096]被包装成std::span后传出函数 → 返回即悬垂，后续访问是未定义行为（UB） - 正确做法：用
std::vector<:byte></:byte>或std::unique_ptr<:byte></:byte>持有数据，再调用.data()和.size()构造std::span - 网络收包场景下，别直接拿
recv()填充的栈数组构造std::span；若必须用栈数组，std::span必须和它同作用域，不可跨函数传参
subspan 切片不自动兜底，必须手动校验 offset + count ≤ size
subspan(offset, count) 是零开销抽象，标准明确禁止运行时检查。传错参数不会崩溃，但会直接越界——比如 buf.subspan(buf.size() + 1) 是 UB，不是空 span。
- 常见错误：解析出 payload 长度
len后直接写buf.subspan(4, len)，却不检查4 + len > buf.size() - 安全写法：切片前加一层校验 ——
if (4 + len > buf.size()) throw std::runtime_error("truncated packet"); - 注意整数溢出陷阱：别写
buf.subspan(4, buf.size() - 4)，当buf.size() 时，<code>size_t减法会回绕成极大值，导致静默失败
operator[] 越界仍是未定义行为，关键字段必须用 at() 或显式 if 校验
std::span::operator[] 行为和原生数组完全一致：不检查索引，越界即 UB。ASan 在 release 模式下不一定能捕获，Debug 模式下部分 STL 实现可能 assert，但不可依赖。
立即学习“C++免费学习笔记（深入）”；
- 协议头中魔数、版本、长度等固定位置字段，建议统一用
span.at(i)，抛异常比静默读脏数据更可控 - 高频循环中避免滥用
at()，但协议解析通常只涉及几字节，这点开销值得 - 若不用
at()，必须手动写if (i ，尤其在 <code>reinterpret_cast或std::bit_cast前——例如读取 4 字节长度字段前，先确认span.size() >= 4
传参必须区分 const 和非 const 视图，类型签名即契约
只读解析和原地修改是两类完全不同语义的操作，std::span 的模板参数必须精确反映意图，否则编译器无法帮你拦截错误。
- 纯解析函数应声明为：
bool parse_header(std::span<const std::byte> data);</const>—— 若误传入可写视图，函数内部试图写会编译失败 - 需要修改原始缓冲区的函数（如重算校验和），必须声明为：
void fix_checksum(std::span<:byte> data);</:byte>—— 若传入 const 视图，编译直接报错 - 从
std::vector<char></char>构造时，必须显式reinterpret_cast<:byte></:byte>或用std::as_bytes()，不能依赖模板推导，否则可能丢失 const 语义或引发类型别名问题
最常被忽略的不是语法怎么写，而是谁在什么时候销毁了底层内存——std::span 不持有所有权，它的“安全”全靠你主动守约。
