直接reinterpret_cast到结构体指针会出错，因为CPU非对齐访问易触发bus error或性能暴跌，且结构体默认内存布局（含填充）与二进制文件字节流不一致，导致字段读取错位。
为什么直接 reinterpret_cast 到结构体指针会出错
因为现代 CPU（x86-64、ARM64）对非对齐访问要么报 bus error（如 ARM 默认配置），要么性能暴跌（x86 允许但慢 2–3 倍）。而二进制文件里的数据天然按字节流排列，结构体字段若没显式对齐，sizeof 和内存布局就和文件内容不一致。比如：
struct Header {
uint32_t magic; // offset 0
uint16_t version; // offset 4 → 但文件里它可能在 offset 5（前一个字段只占 3 字节）
uint8_t flags; // offset 6
};
此时用 reinterpret_cast<Header*>(buf) 会让 version 被解释成从 offset 4 开始的 2 字节，但实际数据在 offset 5，结果错位。
用 std::memcpy + 字段偏移手动填充结构体
这是最可控、零 UB、跨平台安全的做法。核心思路：不依赖结构体内存布局，而是按文件实际字节顺序，逐字段 memcpy 进去。
std::memcpy(&header.magic, buf + 0, sizeof(header.magic));-
std::memcpy(&header.version, buf + 5, sizeof(header.version));← 注意这里不是 +4 std::memcpy(&header.flags, buf + 7, sizeof(header.flags));
关键点：所有偏移量必须来自协议文档或文件格式规范，不能靠 offsetof；memcpy 对任意地址都安全，且编译器通常能优化成单条指令（如 mov）。
立即学习“C++免费学习笔记（深入）”；
用 #pragma pack(1) 强制紧凑布局要谨慎
它能让结构体取消填充字节，看起来“匹配”文件布局，但隐患明显：
- 不同编译器对
#pragma pack的行为不完全一致（尤其嵌套结构或含 bitfield 时） - 即使布局一致，CPU 仍可能因非对齐访问触发异常（ARM64 Linux 默认禁用 unaligned access）
- 结构体一旦用于函数参数传递或 STL 容器（如
std::vector<Header>），紧凑布局会破坏 ABI 兼容性
仅当确认目标平台允许非对齐访问、且结构体**只用于读取映射、绝不作为普通变量使用**时才考虑。更稳妥的替代是用 alignas(1) + static_assert 校验：
#pragma pack(push, 1)
struct Header {
uint32_t magic;
uint16_t version;
uint8_t flags;
};
#pragma pack(pop)
static_assert(sizeof(Header) == 7, "Header layout mismatch");
处理大小端不一致时别碰 ntohl/htons 硬编码
二进制文件常固定用大端（如网络字节序），而 x86 是小端。但直接套用 ntohl 有陷阱：
-
ntohl接收uint32_t，你得先正确读出 4 字节再传入——如果结构体本身非对齐，ntohl(*reinterpret_cast<uint32_t*>(buf+0))仍可能 crash - 更可靠的是先
memcpy到临时变量，再转换：
uint32_t raw_magic; std::memcpy(&raw_magic, buf + 0, sizeof(raw_magic)); header.magic = be32toh(raw_magic); // POSIX，或用 std::byteswap（C++23）
注意：be32toh 比 ntohl 更语义清晰（明确表示“big-endian to host”），且部分平台对 ntohl 有符号扩展 bug。
真正麻烦的从来不是怎么读，而是当字段类型含 padding、bitfield、变长数组或嵌套子结构时，偏移计算极易出错——建议把每个字段的文件偏移、长度、字节序写成 constexpr 表，在编译期校验总长度与协议一致。
