现代.NET中非对齐指针操作的安全性与跨平台兼容性问题

你当前在x86/x64设备上测试全量通过，本质是该系列硬件架构默认兼容非对齐内存访问的特性导致，并非代码本身符合跨平台安全规范。

不同读写方式的安全边界 #

• Unsafe.ReadUnaligned<T>/Unsafe.WriteUnaligned<T>：这组API是绝对安全的，是.NET专门为非对齐内存场景设计的。无论运行在哪种硬件架构、哪种操作系统上，JIT都会生成适配当前平台的代码：如果硬件原生支持非对齐访问，就直接生成普通访问指令；如果硬件不支持，JIT会自动生成按字节拆分读写、拼接结果的逻辑，永远不会出现崩溃或数据错误，唯一的影响仅为性能差异，完全可以放心使用。
• Unsafe.Read<T>/Unsafe.Write<T>（无Unaligned后缀）：这组API的显式使用约定就是传入指针必须满足类型T的对齐要求，传入非对齐指针属于明确的未定义行为。你在x86/x64上运行正常，是因为这两个架构下普通整数、普通结构体的读写指令本身兼容非对齐地址，只会产生性能损耗不会触发错误；但换到严格要求对齐的硬件架构上，JIT生成的对齐访问指令碰到非对齐地址会直接触发硬件异常。
• 直接指针解引用（即你代码中*(MyStructPacked*)(ptr + 3)、*(uint*)(ptr +5)这类写法）：行为和无Unaligned后缀的Unsafe.Read/Write完全一致。C#语言规范明确要求，这类值类型指针解引用操作的源地址必须满足对应类型的对齐要求，非对齐地址下的行为没有任何规范保障。

非对齐违规访问的最坏后果 #

• 最常见的故障：在ARMv7及更早的32位ARM架构、部分MIPS、RISC-V配置下，非对齐的对齐访问指令会直接触发总线错误（SIGBUS），进程直接崩溃，这类异常无法在用户态捕获，程序会直接退出。
• 隐性性能灾难：部分架构（比如部分ARM64配置）的内核会开启非对齐访问模拟，这种场景下程序不会崩溃，但每次非对齐访问都会触发内核态陷阱，性能会比正常访问低2-3个数量级，且没有明显报错，极难排查。
• 静默数据损坏：在弱内存序架构上，如果非对齐访问的地址跨了缓存行边界，在并发写入场景下可能读到只写了一半的脏数据，程序不会崩溃，但会出现完全随机的逻辑错误，这类问题几乎无法调试。

问题复现方式 #

• 最容易复现的环境：使用32位ARM设备（比如树莓派Zero、老款树莓派2安装32位系统）安装.NET 6+运行时，直接运行你提供的测试代码，在执行直接指针解引用、无Unaligned后缀的Read<uint>调用时，会直接触发SIGBUS崩溃。
• 即使在x64平台也可以复现：如果你把读写的目标类型换成要求16/32字节对齐的SIMD类型（比如Vector128<uint>、Vector256<uint>），非对齐地址下调用对齐读写指令会直接触发崩溃，和架构无关。

开发建议 #

• 如果你确定要操作非对齐地址的结构体数据，全程只使用Unsafe.ReadUnaligned和Unsafe.WriteUnaligned，不要用无Unaligned后缀的API，也不要直接对非对齐指针做解引用，这样的代码在所有.NET支持的平台上都是稳定安全的。
• 如果需要兼顾性能，可以在读写前先判断指针地址是否满足目标类型的对齐要求：对齐的场景走直接解引用/无Unaligned后缀的API，非对齐场景走Unaligned系列API，这也是.NET运行时内部处理内存读写的标准写法。
• 不要依赖x86/x64平台上的测试结果判断安全性。未定义行为意味着哪怕在当前平台正常，未来的JIT版本更新、不同的代码优化等级下，都有可能出现异常，微软不会为这类违规使用场景提供任何兼容性承诺。

内容的提问来源于stack exchange，提问作者Nikita B