因为结构体成员间存在编译器插入的填充字节，且非对齐访问在ARM/RISC-V等架构上会触发Bus error或静默错误；必须用std::memcpy逐字段安全搬运，而非reinterpret_cast解引用。
为什么直接用 &struct_member 可能得不到预期偏移？
结构体成员在内存中默认按对齐要求布局，编译器可能在成员间插入填充字节。当你想通过基地址加固定偏移访问某个成员（比如解析二进制协议或映射硬件寄存器），而该成员本身不满足自然对齐（如 uint16_t 在奇数地址），reinterpret_cast 直接解引用会触发未定义行为——尤其在 ARM 或 RISC-V 等严格对齐架构上，直接读写非对齐地址会抛 Bus error 或静默数据错误。
用 std::memcpy 安全读取非对齐成员
这是最便携、标准推荐的方式：绕过指针解引用的对齐检查，把内存块原样拷贝到对齐变量中。适用于所有 C++11 及以上标准。
- 不能用
*reinterpret_cast<T*>(ptr)，哪怕你知道类型大小一致 - 必须用
std::memcpy逐字节搬运，让编译器生成安全的加载指令（如 ARM 的ldrh+ 拆解，或 x86 的mov+ 掩码） - 目标变量必须是自动存储期的对齐变量（栈上或全局），不能是位域或 packed 结构体内嵌的临时对象
struct Packet {
uint8_t header;
uint16_t payload_len; // 假设它被强制放在 offset=1 处（非对齐）
uint32_t crc;
};
// 假设 data 是 uint8_t*，指向一个按需打包的缓冲区
uint16_t len;
std::memcpy(&len, data + 1, sizeof(len)); // ✅ 安全
用 __packed 或 #pragma pack 控制结构体布局时要注意什么？
这类指令只影响结构体内部成员排布，不改变 CPU 对单个字段访问的对齐要求。即使你用 #pragma pack(1) 让 uint16_t 紧挨在 uint8_t 后面，读它仍需非对齐支持。
-
#pragma pack(1)在 GCC/Clang 中等价于__attribute__((packed))；MSVC 用#pragma pack(push, 1) - 加了
packed的结构体成员地址仍是非对齐的，不能直接解引用 - 某些平台（如 ARM64 默认）禁用非对齐访问，即使结构体 packed，
*(uint16_t*)(ptr)仍会 crash - 如果必须用指针访问，GCC 提供
__attribute__((aligned(1)))类型修饰符，但仅限于声明变量，不能用于 cast
什么时候可以跳过 memcpy 直接访问？
仅当明确知道目标平台允许且编译器生成了非对齐指令——但这不是可移植做法，也不该作为默认策略。
立即学习“C++免费学习笔记（深入）”；
- x86/x64 通常允许非对齐访问（性能略降），但不等于“安全”：SSE/AVX 指令仍要求对齐，混用易出错
- ARMv7+ 可通过
SETEND或内核配置开启非对齐访问，但用户态程序无法依赖 - Clang/GCC 的
-mno-unaligned-access（ARM）或-mstrict-align会禁用隐式非对齐优化，此时连 memcpy 都可能被优化成非法指令 - 真正需要性能极致的场景（如网络包解析），应使用平台专用 intrinsic，如
__builtin_unaligned_load16（GCC）或_loadu16（ARM Neon），但它们不是标准 C++
实际工程中，只要求跨平台或不确定运行环境，std::memcpy 就是唯一靠谱选择。别省那几纳秒——非对齐访问的代价远不止性能，还有静默错误和平台迁移成本。
