#[repr(packed)]属性源于系统编程的要求，内存布局必须与外部规格（例如硬件寄存器或网络协议）匹配，通过消除字段之间的填充字节来实现。虽然Rust通常保证引用与它们指向类型的要求对齐，但打包结构强制字段根据字节偏移 sequential，无论对齐如何，这可能导致u32位于一个无法被四整除的地址上。尝试创建对这样的未对齐字段的引用（&或&mut）构成立即的未定义行为，因为编译器和LLVM在进行如向量化或原子操作的优化时假定地址是对齐的。为了安全访问数据，必须完全避免创建中间引用，而是使用addr_of!和addr_of_mut!宏直接获得原始指针，然后使用ptr::read_unaligned或ptr::write_unaligned在没有对齐假设的情况下复制数据。
use std::ptr::{addr_of, read_unaligned}; #[repr(packed)] struct Packet { flags: u8, timestamp: u64, // 可能在偏移量1处，未对齐 } fn get_timestamp(p: &Packet) -> u64 { // UB: &p.timestamp 会创建一个未对齐的引用 let raw_ptr = addr_of!(p.timestamp); unsafe { read_unaligned(raw_ptr) } }
在开发一个零拷贝解析器用于二进制金融协议（FIX）时，团队要求一个完全匹配 wire 格式的结构：一个u8消息类型，后面紧接着一个u64时间戳而没有填充。初始实现使用**#[repr(packed)]和直接字段访问，导致在ARM**架构上间歇性段错误，其中未对齐的访问会导致陷入内核。
评估了几种解决方案。首先，使用移位和按位或操作逐字节手动重建：这消除了对齐问题，但引入了每个数据包显著的 CPU 开销和容易出错的位操作逻辑，复杂了审计。第二，使用**#[repr(C)]和显式填充字段强制对齐：这保证了安全性，但通过更改后续字段的字节偏移破坏了协议兼容性，需要昂贵的内存拷贝来重新排列数据以进行传输。第三，保留#[repr(packed)]**，但仅通过原始指针访问字段，进行未对齐读取：这保持了精确的内存布局，同时避免通过未创建对齐引用访问时间戳字段而引发的未定义行为。
团队选择了第三种方案，实施了一个进行getter方法，使用addr_of!(self.timestamp)，然后使用ptr::read_unaligned返回时间戳值。消除了在ARM和x86_64上的崩溃，同时保留了零拷贝架构，比起逐字节重建方法，将延迟减少了40%。
为什么创建对未对齐字段的引用构成未定义行为，即使是在支持未对齐访问的架构上？
尽管x86_64处理器在硬件级别上宽容未对齐加载，但Rust的未定义行为规则比硬件能力更严格，以实现积极的优化。当编译器看到&u32时，它假定地址是四字节对齐的，允许它生成SIMD指令，优化掉后续的对齐检查，或者重新排列内存操作。违反这一假设——即使在宽容的硬件上——允许编译器错误编译代码，可能在未来的编译器版本或不同架构上导致崩溃或静默的数据损坏。
addr_of!宏在语义上与应用于打包结构字段的&操作符有何不同？
&操作符在概念上首先创建一个引用，然后如果分配给一个原始指针，强制转换为原始指针，因此立即触发对齐有效性检查。相比之下，addr_of!是一个内建宏，直接计算地址而不创建中间引用，从而完全绕过了对齐要求。这一区别至关重要，因为addr_of!返回的*const T可能是未对齐的，而&field如果字段未对齐将是UB，即使立即被转换为指针。
为什么对包含非复制字段的打包结构实现Drop会存在问题，如何安全地实现自定义销毁？
Drop::drop方法接收&mut self，这是对齐的（结构本身保持整体对齐），但删除单个字段需要以&mut Field调用它们的析构函数。如果一个字段的对齐高于结构开始位置，从而未对齐，创建&mut Field以调用Drop是不定义行为。为了安全地删除这样的结构，必须将非复制字段包装在ManuallyDrop中，然后在自定义Drop实现中，对通过addr_of_mut!获得的原始指针使用ptr::read_unaligned或ptr::drop_in_place，确保析构函数运行时，不会创建对未对齐字段的对齐引用。