必须加#pragma pack(1)或[[gnu::packed]]禁用填充，并用static_assert校验大小；嵌套数组不可直接退化为一维指针，应取&buf0获取首地址。
用 memcpy 直接解包前必须确认内存布局对齐
定长数组嵌套结构在二进制协议里常见，比如 struct Packet { int header; char data[4][8]; };。C++ 编译器默认会按成员大小做对齐（如 int 对齐到 4 字节），导致结构体实际大小可能大于字段字节总和——这时直接 memcpy 到结构体变量，数据会错位。
实操建议：
- 所有协议结构体必须加
#pragma pack(1)或[[gnu::packed]]，禁用填充 - 用
static_assert(sizeof(MyStruct) == expected_size, "size mismatch");在编译期卡死不一致 - 别依赖
offsetof算偏移，它受对齐影响；改用sizeof累加字段大小来验证
嵌套数组的指针退化陷阱：别用 data[0] 当一维首地址
像 char buf[4][8] 这种二维定长数组，&buf[0][0] 和 buf[0] 类型不同：buf[0] 是 char[8]，传参时退化为 char*，但 buf 整体是 char[4][8]，不能直接当 char* 用。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 把整个结构体
memcpy过来后，想用for (int i = 0; i —— 没问题 - 但若写成
process((char*)buf);并期望它等价于&buf[0][0]，在pack(1)下虽可行，但语义模糊、易被后续修改破坏 - 更危险的是：用
std::span<char>(buf, sizeof(buf))</char>时，buf不是数组名而是左值，类型推导失败
正确做法：显式取址，std::span<const char>(&buf[0][0], sizeof(buf))</const>。
反序列化时避免手动展开嵌套循环
遇到 struct { uint8_t items[16][32][4]; } 这类三层嵌套，手写三重 for 解析既啰嗦又易错索引顺序（行主序 vs 列主序）。
实操建议：
- 用
std::array替代 C 风格数组，支持data()和范围 for：std::array<:array>, 32>, 16> items;</:array> - 如果协议要求紧凑二进制且不能改结构体定义，就封装一个视图类，内部用
reinterpret_cast+ 偏移计算，但必须加static_assert校验各层 stride - 别在运行时算下标：例如
items[i][j][k]应该对应原始 buffer 中位置i * 32 * 4 + j * 4 + k，这个乘法常量应由编译器折叠，不要写成i * sizeof(layer2) + ...
跨平台解析要小心 uint8_t 和 char 的符号性差异
协议里存的是无符号字节流，但 C++ 中 char 可能是 signed，直接读进 char[] 再 reinterpret_cast 成 uint16_t，在负值高位扩展时会出错。
使用场景：
- 解析
uint16_t len字段时，若从char buf[2]构造，得先转unsigned char再组合：(static_cast<uint16_t>(buf[0]) (buf[1])</uint16_t> - 用
std::memcpy到uint16_t变量没问题，但前提是源 buffer 类型是const unsigned char*，否则可能触发未定义行为（严格别名规则） - Clang/GCC 开启
-fno-strict-aliasing不是解法，应统一用std::bit_cast（C++20）或memcpy显式转换
嵌套数组的每一层都可能是字节边界，这种类型安全细节漏一处，整包解析就静默错乱。
