std::span的subspan()不作运行时边界检查，因其是零开销抽象，仅做指针偏移和长度更新；必须手动校验offset+count≤span.size()以避免未定义行为。
std::span 本身不提供子缓冲区（sub-buffer）的自动安全保证，所有“切片”操作都依赖你手动校验边界；subspan() 不检查参数合法性，传错 offset 或 count 会直接导致越界访问——不是编译错误，而是未定义行为（UB）。
为什么 subspan() 不做运行时边界检查
subspan() 是零开销抽象，标准明确要求它不执行任何运行时校验。它的两个重载：subspan(size_t offset) 和 subspan(size_t offset, size_t count)，都只做指针偏移和长度更新，不验证 offset + count 。
- 常见错误现象：解析协议头后写
buf.subspan(4, len)，但没提前检查len > buf.size() - 4→ 后续payload.at(0)抛异常，或payload[0]读脏数据 - 使用场景：二进制协议解析、文件头提取、网络包分段处理
- 性能影响：加校验是 O(1) 比较，但省掉它可能换来崩溃或静默数据损坏——别为这点开销赌运气
- 正确做法始终是：先用
if (buf.size() 做总长兜底，再用 <code>if (offset + count > buf.size())校验切片合法性
std::span<const std::byte></const> 是子 Buffer 视图的推荐类型
用 std::span<const std::byte></const> 而非 std::span<const char></const> 或裸 uint8_t*，能从类型系统上阻止误写、强制只读语义，并与 C++20 的内存操作工具（如 std::as_bytes()、std::bit_cast()）自然对齐。
- 避免隐式转换陷阱：从
std::vector<char></char>构造时，必须显式reinterpret_cast<:byte></:byte>或用std::as_bytes()，不能依赖模板推导 - const 正确性：传给解析函数时若标记为
const std::byte，编译器会拦住任何试图修改 payload 的代码 - 兼容性注意：某些旧接口要
char*，此时需用reinterpret_cast<char>(view.data())</char>，但务必确认目标函数不会释放或长期持有该指针
子 Buffer 生命周期比父 Buffer 短？这是典型悬垂陷阱
子 std::span 的生命周期可以短于父 std::span，但绝不能长于底层内存本身。很多人以为“切片出来的 span 更小，所以更安全”，结果把 subspan() 结果存成成员变量或返回值，而父缓冲区（比如局部 std::vector）已析构。
立即学习“C++免费学习笔记（深入）”；
- 常见错误现象：函数返回
std::span<const std::byte></const>，内部却基于局部std::vector<:byte> buf</:byte>构造 → 返回即悬垂 - 安全做法：子视图只能在父缓冲区作用域内使用；若需跨作用域，必须让底层内存（如
std::shared_ptr<:vector>></:vector>）存活足够久 - 参数差异：传入函数用
std::span<const std::byte></const>，传出结果用std::optional<:span std::byte>></:span>或直接返回结构体（含数据拷贝），别传裸视图 - 调试提示：启用
-D_GLIBCXX_ASSERTIONS可让at()在 debug 模式下触发断言，但无法防护subscript或subspan错误
真正危险的从来不是看不懂的错误，而是看似运行正常却悄悄读错字节的 subspan() 调用——它不报错、不警告，只在某个特定文件、某个特定偏移处让程序逻辑悄然偏移。每次调用前那行 if (offset + count > parent.size())，不是冗余，是唯一能拦住 UB 的栅栏。
