非对齐访问在ARM和RISC-V上会导致卡顿或异常，因其硬件不支持单周期跨边界读取，需拆分为多次访存并拼接，而x86靠微指令补救但代价高；ARMv7默认抛Alignment fault，ARMv8默认禁用；常见于packed结构体、指针强转等场景，可用-Wcast-align和/proc/cpu/alignment检测，修复应优先采用字节搬运而非padding。
非对齐访问在 ARM 和 RISC-V 上为什么会卡顿
因为这些架构的 CPU 硬件不支持单周期读取跨边界的内存块。比如 uint32_t 本该从地址 0x1000（4 字节对齐）读，但你让它从 0x1001 读——CPU 得拆成两次访存 + 拼接，延迟翻倍甚至触发异常。
x86 看似“允许”，其实是靠微指令偷偷补救，代价是缓存行失效、TLB 压力增大；而 ARMv7 默认直接抛 Alignment fault，ARMv8 则默认禁用非对齐访问（除非显式开启 SETUP_ALIGNMENT_TRAP 或编译器插桩）。
- 常见错误现象：
Bus error (core dumped)（ARM Linux）、Instruction fetch failed（裸机 RISC-V） - 典型场景：用
memcpy搬运结构体字段偏移不齐的数据、强制类型转换指针如(uint32_t*)buf+1 - 编译器不会自动帮你对齐——
__attribute__((packed))结构体成员就是为制造非对齐而生的
怎么一眼看出代码里藏着非对齐访问
别等跑崩了再查。静态看三处：struct 定义、指针算术、reinterpret_cast / C 风格强转。
例如这个结构体：
立即学习“C++免费学习笔记（深入）”；
struct Header {
uint8_t flag;
uint32_t len; // 实际偏移是 1，不是 4
} __attribute__((packed));只要有人写 auto p = (uint32_t*)&hdr.len;，就踩坑了。
- Clang/GCC 加
-Wcast-align能报出大部分危险强转 - 运行时检测：ARM Linux 可临时开
echo 1 > /proc/cpu/alignment，它会把每次非对齐访问记进 dmesg 并打 backtrace - 注意：
memcpy(&dst, &src, 4)是安全的——编译器知道生成对齐友好的指令，哪怕 src/dst 地址本身不对齐
真正靠谱的修复方式不是“加 padding”而是“绕开地址计算”
手动在结构体里塞 uint8_t pad[3] 确实能对齐，但浪费空间、破坏协议兼容性，且一旦字段顺序变，padding 就失效。
更稳的做法是放弃“指针直取”，改用字节搬运 + 解包逻辑：
uint32_t load_le32(const uint8_t* p) {
return p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24);
}- 性能不差：现代编译器对这种固定偏移的
load_le32会内联并优化成单条ldrh+ldrb或向量指令 - 兼容性拉满：无论
p是0x1000还是0x1003都能跑 - 别信
__builtin_unaligned_load：GCC 的这个 builtin 在 ARM 上只是关 alignment check，并不加速——它还是走慢路径
std::memcpy 和 std::bit_cast 的边界在哪
std::memcpy 是 C++ 里唯一被标准明确认可的“合法越界搬运”手段，只要目标对象足够大、类型 trivially copyable，它就能绕过对齐限制安全工作。
而 std::bit_cast（C++20）要求源和目标类型大小相同且对齐兼容——它不处理非对齐，传进去一个未对齐指针会触发未定义行为。
- 正确用法：
uint32_t x; memcpy(&x, buf+1, sizeof(x));✔️ - 危险用法：
auto x = std::bit_cast<uint32_t>(*(const uint32_t*)(buf+1));</uint32_t>❌（先解引用未对齐指针） - 工具链差异：ARM clang 默认生成
unaligned指令（需-mno-unaligned-access关），GCC 则默认保守生成对齐检查代码
硬件差异比想象中顽固：哪怕同一份二进制，在 Cortex-A53 和 A72 上的非对齐惩罚可能差 3 倍。别假设“以前跑得过就永远没问题”。
