StructLayout的Pack参数需权衡内存与性能：Pack=0按平台自然对齐（如x64为8字节），访问快但可能浪费空间；Pack=1紧凑布局省内存，但非对齐访问在ARM或老x86上会变慢；纯传输用Pack=1，高频读写用Pack=0，混合场景可拆分结构体。
StructLayout 的 Pack 参数怎么选
选 Pack 本质是在内存占用和 CPU 访问效率之间做权衡。默认 Pack = 0 表示让运行时按目标平台自然对齐（x64 下通常按 8 字节对齐），这时访问最快，但可能因填充字节浪费空间；设成 Pack = 1 能压紧结构体、节省内存，但若字段跨缓存行或触发非对齐访问，在某些 CPU（尤其是 ARM 或老款 x86）上会明显变慢。
常见做法：
- 纯数据传输（如序列化、网络收发、GPU Buffer）优先用
Pack = 1，避免接收端解析错位 - 高频内存读写（如粒子系统、帧间缓存数组）保持
Pack = 0，让 CPU 单次加载更高效 - 混合场景可拆分：用
[StructLayout(LayoutKind.Sequential, Pack = 1)]定义传输结构体，再在运行时拷贝到Pack = 0的工作结构体中处理
LayoutKind.Explicit 为什么容易出错
手动指定 FieldOffset 看似完全可控，但极易破坏 CPU 对齐假设。比如在 x64 上把一个 long（8 字节）放在偏移 3 处，会导致每次读写都触发对齐异常（.NET 会自动修复但代价是额外指令+寄存器搬移），实测吞吐量可能下降 20%～40%。
除非以下情况，否则不建议用 Explicit：
- 必须与 C/C++ 结构体二进制完全一致（如调用 Windows API 或驱动通信）
- 字段存在重叠（如 union 模拟），且已确认目标平台支持非对齐访问
- 做了充分的基准测试，证明当前 offset 组合在目标硬件上无性能劣化
错误示例：[FieldOffset(3)] public long Value; —— 在多数 x64 进程中会悄悄变慢，且 dotnet trace 很难直接定位。
struct 大小变化如何影响 GC 和缓存行
结构体大小不是越小越好。若一个 struct 从 24 字节变成 32 字节，刚好跨过缓存行边界（典型 64 字节），单个实例仍只占一行；但若从 64 字节变成 65 字节，就强制占用两行，CPU 预取和 L1 缓存命中率会明显下降。
同时注意 GC 压力：当 struct 作为字段嵌套在 class 中，或大量存在于 ListUnsafe.SizeOf<t>()</t> 在编译期检查实际尺寸，比靠经验估算可靠。
关键点：
- 用
dotnet-counters --process-id <pid> Microsoft-DotNetCore-EventPipe GC/AllocationTick</pid>观察大 struct 是否推高分配率 - 用
PerfView查看Microsoft-Windows-DotNETRuntime/JIT/MethodJitted事件，确认是否因 struct 搬移导致频繁 JIT 内联失败 - 避免让 struct 成员含引用类型（如
string），否则失去栈分配优势，还引入 GC 扫描开销
Span 和 Memory 场景下 StructLayout 更敏感
当用 Span<byte></byte> 或 MemoryMarshal.AsRef<t></t> 直接 reinterpret 内存时，StructLayout 错误会立刻暴露为 AccessViolationException 或静默数据错乱——因为此时绕过了 CLR 的字段安全检查。
必须确保：
- 目标 struct 是
unmanaged类型（无引用、无 finalizer、无 auto-layout） -
Pack值与原始内存布局严格一致（例如从 C++ memcpy 过来的 buffer） - 用
Unsafe.AreSame<t>(ref a, ref b)</t>或Unsafe.ReadUnaligned<t></t>替代直接AsRef，可规避部分对齐风险
一个易忽略的坑：sizeof(T) 和 Unsafe.SizeOf<t>()</t> 在 LayoutKind.Auto 下结果可能不同，而后者才是底层内存操作的真实依据。
