必须显式声明[structlayout(layoutkind.sequential)]以锁定字段内存顺序，防止clr优化重排；含非blittable字段时仅影响封送布局，而pack参数需与c/c++端严格一致（如pack=1用于网络包、pack=4适配windows api），explicit仅用于联合体或共享内存等特殊场景。
不用加 [StructLayout(LayoutKind.Sequential)] 也能和 Windows API 正常交互，但加了才真正可控；不设 Pack 或乱用 LayoutKind.Explicit，轻则字段错位、数据解析全乱，重则 P/Invoke 崩溃或跨平台失效。
什么时候必须显式写 [StructLayout(LayoutKind.Sequential)]
结构体默认就是 Sequential，但显式声明不是为了“补全语法”，而是为后续扩展留出控制权。比如你一开始只调用一个 API，没加特性也能跑通；但后续要对接 C++ DLL 或写入二进制协议头时，如果没提前锁定布局，CLR 可能在优化中悄悄重排字段（尤其含引用类型或泛型时）。显式写上，等于告诉编译器：“这个结构体的内存顺序，从现在起不允许动”。
- 类（
class）默认是Auto，必须加才能保证顺序 —— 这是高频踩坑点，别被结构体的默认行为带偏 - 含
string、object、委托等非 blittable 字段时，Sequential只影响封送（marshaling）时的非托管布局，不影响托管内存中的实际排列 - 若结构体里有
fixed数组或unsafe指针，Sequential是强制前提，否则编译报错
Pack 参数怎么选：1、4、8 不是随便填的
Pack 控制的是字段对齐边界，它直接决定填充字节（padding）是否插入、插多少。选错值会导致字段地址偏移与 C/C++ 端不一致 —— 比如 C 头文件里 struct { uint8_t a; uint32_t b; } 在 Pack=1 下是紧凑的 5 字节，但在默认 Pack=8 下会变成 8 字节（a 后插 3 字节 padding，再放 b）。
-
Pack = 1：禁用自动填充，适合网络包、硬件寄存器映射、或已知 C 端也用了#pragma pack(1) -
Pack = 4：平衡兼容性与空间，Windows API 多数结构（如RECT、POINT）默认按 4 对齐，C++ 侧通常用#pragma pack(4) -
Pack = 0：用当前平台默认对齐（x64 是 8），但跨平台时不可靠，不建议用于互操作场景 - 千万别混用：C++ 侧是
Pack=2，C# 写成Pack=4，int后的byte就可能被错读成下一个字段的高位
LayoutKind.Explicit 的真实使用场景和风险
Explicit 不是用来“炫技”的，它是解决共享内存、联合体（union）、或协议字段复用的最后手段。比如解析一个 16 字节的网络头，前 4 字节既是 uint32_t flags，又可拆成 4 个 uint8_t 标志位 —— 这时就得用 [FieldOffset(0)] 让多个字段指向同一块地址。
- 必须配
[FieldOffset]，每个字段偏移量需手动算清，且不能重叠非法（如[FieldOffset(0)] int a;和[FieldOffset(2)] byte b;在 x86 上合法，但在 ARM 上可能触发未对齐访问异常 -
Size参数要显式指定（如[StructLayout(LayoutKind.Explicit, Size = 16)]），否则 CLR 可能按最大字段对齐后向上取整，导致实际大小超出预期 - 含字符串或数组时，
Explicit无法直接封送，得用IntPtr+ 手动Marshal，复杂度陡增 - 调试困难：字段地址不再由声明顺序决定，
&s.field的结果必须靠unsafe验证，IDE 调试器可能显示错误值
容易被忽略的细节：CharSet、blittable 类型与性能暗示
很多人只盯着 LayoutKind 和 Pack，却忘了 CharSet 会影响字符串字段的封送行为，而字段是否是 blittable 类型，决定了整个结构体能否零拷贝传递。比如 char[] 默认是 Unicode，但 C API 期望 ANSI，不设 CharSet = CharSet.Ansi 就会多一次编码转换。
- blittable 类型（如
int、float、byte）在托管/非托管内存中二进制表示一致，封送开销≈0；非 blittable（如string、DateTime）必有复制和转换 - 结构体里只要有一个非 blittable 字段，整个结构体就失去“零拷贝”资格，
Sequential只控制封送时的布局，不改变运行时托管堆上的布局 -
Size参数在Sequential下仅作提示（CLR 可能忽略），但在Explicit下是硬约束，写小了会导致越界读写 - 高频调用场景（如每帧传几百个
Vector3给原生渲染库），优先用全 blittable 字段 +Pack=4+ref struct避免 GC 压力
