企业官网建设流程全解析

值类型与 struct 的正确使用

篇章：08-核心技术-性能优化篇 |阅读时间：约 45 分钟

一、引言

值类型（value type）是 C# 中优化 GC 分配的重要工具。正确使用struct可以在特定场景下完全消除堆分配——局部变量在栈上分配，数组元素内嵌在数组的连续内存中，方法参数通过值拷贝传递。但struct不是免费午餐——错误使用可能比class更差，产生比预期多一个数量级的拷贝开销，甚至在某些情况下间接导致更多的 GC 分配。

理解struct的内存布局、拷贝语义和 GC 影响，是写出高效 C# 代码的基础。本章将从内存模型出发，深入分析struct的分配行为、常见陷阱、优化策略，以及readonly struct、ref struct等现代 C# 特性的正确用法。

在展开之前先把本章的定位说清楚。08-01 到 08-04 已经分别分析了字符串、LINQ、闭包和装箱的 GC 陷阱，本章聚焦值类型本身——它是所有零分配优化的底层基础。08-07 Span 篇会用到本章的stackalloc和ref struct知识，08-04 装箱篇会回指本章的装箱机制分析。

二、值类型的内存模型

2.1 栈上分配 vs 堆上分配

C# 的类型系统分为值类型（struct、enum、基本数值类型）和引用类型（class、delegate、interface实现）。它们的内存分配位置有本质区别：

// struct 局部变量 → 栈上分配 Vector3 v = new Vector3(1, 2, 3); // 栈上 12 字节 // class 局部变量 → 引用在栈上，对象在堆上 MyClass obj = new MyClass(); // 栈上 8 字节（引用）+ 堆上 24 字节（对象头 + 字段）

栈上分配的优势：

1. 零 GC：栈上内存随函数返回自动释放，不经过 GC 管理。
2. 零分配开销：栈指针减法（sub rsp, N）即可完成分配，通常只需 1 条指令。
3. 极致缓存局部性：栈内存按时间局部性组织，近期分配的数据最可能被访问。

堆上分配的优势：

1. 生命周期不受函数作用域限制：堆对象可以跨函数调用存活。
2. 统一引用语义：所有引用类型共享同一个引用传递模型。
3. 支持虚方法和接口：引用类型天然支持多态。

理解这个区别是分析structGC 行为的前提。struct在栈上分配时零 GC，但一旦struct被装箱、作为class的字段、或存储在List<T>等堆分配集合中，它就会间接产生堆分配。

2.2 struct 的内存布局

struct在内存中的布局由字段类型和排列方式决定：

public struct PlayerStats { public int Health; // offset 0, 4 bytes public float Speed; // offset 4, 4 bytes public int Level; // offset 8, 4 bytes public bool IsAlive; // offset 12, 1 byte // padding: // offset 13, 3 bytes (对齐到 4 字节边界) // Total: 16 bytes }

struct的内存布局规则：

1. 字段按声明顺序排列：编译器不重新排列字段（与class不同）。
2. 对齐填充：每个字段的偏移量必须是其大小的整数倍。如果不够，编译器插入填充字节。
3. struct总大小：必须是其最大字段大小的整数倍。例如最大字段是 8 字节（long/double/引用），struct总大小必须是 8 的倍数。
4. 嵌套struct：嵌套struct的字段按嵌套顺序展平排列。

// 对齐填充的示例 public struct BadPacked { public byte A; // offset 0, 1 byte public long B; // offset 8, 8 bytes (需要 8 字节对齐，跳过 7 字节填充) public byte C; // offset 16, 1 byte // padding: // offset 17, 7 bytes // Total: 24 bytes } public struct GoodPacked { public long B; // offset 0, 8 bytes (最大字段放前面) public byte A; // offset 8, 1 byte public byte C; // offset 9, 1 byte // padding: // offset 10, 6 bytes // Total: 16 bytes (比 BadPacked 省 8 字节！) }

这个细节在高性能场景中非常重要——一个 24 字节的struct比 16 字节的struct多 50% 的内存占用，意味着缓存行利用率降低 33%。

2.3 struct 数组 vs class 数组

struct数组和class数组在内存布局上有本质区别：

// struct 数组：连续内存，一次分配 Vector3[] points = new Vector3[1000]; // 内存布局：[V3][V3][V3][V3]...[V3] ← 连续 12000 字节，1 次分配 // class 数组：引用数组 + 独立对象分配 MyClass[] objs = new MyClass[1000]; // 内存布局： // 引用数组：[ref][ref][ref]...[ref] ← 连续 8000 字节（64 位），1 次分配 // 堆对象： [Obj][Obj][Obj]...[Obj] ← 1000 次独立分配，分散在堆上

这种布局差异带来以下影响：

在 Unity 中，Vector3[]是性能敏感代码的默认选择——例如粒子系统的位置数据、物理引擎的碰撞点数据。100 万个Vector3的struct[]只需一次 12MB 的分配，而 100 万个class对象可能需要 100 万次分配和 28MB+ 的堆空间。

三、struct 的拷贝语义

3.1 值拷贝的代价

struct的核心语义是值语义——每次赋值、每次方法参数传递、每次属性访问（如果是值类型），都会产生一次完整的内存拷贝。这个拷贝的代价取决于struct的大小：

public struct SmallStruct // 12 字节 { public float X, Y, Z; } public struct LargeStruct // 64 字节 { public float A, B, C, D, E, F, G, H; public float I, J, K, L, M, N, O, P; } // 拷贝 12 字节：通常 1 条 movaps 指令（128 位） SmallStruct a = new(); SmallStruct b = a; // 1 次拷贝 // 拷贝 64 字节：需要 4 条 movaps 指令（4 × 128 位） LargeStruct c = new(); LargeStruct d = c; // 4 次拷贝

在 x86-64 上，movaps（128 位）或vmovdqu（256 位 AVX）指令可以在 1 个时钟周期内拷贝 16 或 32 字节。所以：

• 12 字节拷贝：约 1 纳秒
• 64 字节拷贝：约 4 纳秒
• 256 字节拷贝：约 16 纳秒

这些时间看起来微不足道，但在热路径中（如Update每帧调用数百次），累积开销可能达到微秒级，影响帧率。

3.2 方法参数的拷贝

方法参数传递是struct拷贝最常见的场景：

// ❌ 按值传递大 struct → 完整拷贝 void Process(LargeStruct data) { // data 是拷贝，修改不影响原始值 } Process(largeValue); // 64 字节拷贝 // ✅ 按 ref 传递 → 传递指针，零拷贝 void ProcessRef(ref LargeStruct data) { // data 是原始值的引用，修改影响原始值 } ProcessRef(ref largeValue); // 8 字节指针拷贝 // ✅ 按 in 传递（只读）→ 传递指针，零拷贝，编译器保证不修改 void ReadOnly(in LargeStruct data) { float sum = data.A + data.B; // 只读访问 } ReadOnly(in largeValue); // 8 字节指针拷贝

ref、out、in参数是 C# 7.0 引入的优化手段，它们传递的是隐藏的指针（8 字节），而不是完整的struct拷贝。这在处理大于 32 字节的struct时特别重要。

3.3 属性访问的拷贝陷阱

属性访问是struct拷贝最隐蔽的来源。当属性返回struct类型时，每次访问都会返回一个拷贝：

public struct Rect { public float X, Y, Width, Height; // ❌ 这个属性每次访问都返回拷贝！ public Vector3 Center // 返回 Vector3（12 字节拷贝） { get => new Vector3(X + Width / 2, Y + Height / 2, 0); } } Rect rect = new Rect { X = 0, Y = 0, Width = 100, Height = 100 }; // ❌ 每次访问 Center 都创建新的 Vector3 Vector3 c1 = rect.Center; // 创建 Vector3(50, 50, 0) Vector3 c2 = rect.Center; // 又创建 Vector3(50, 50, 0) // ✅ 缓存到局部变量 Vector3 center = rect.Center; // 只创建一次

这个陷阱在 Unity 中特别常见。transform.position返回Vector3，每次访问都产生 12 字节拷贝。虽然 12 字节的拷贝代价很低（约 1 纳秒），但在循环中访问数百次时，累积开销可能达到微秒级。

// ❌ 循环中频繁访问 transform.position for (int i = 0; i < 100; i++) { transform.position += Vector3.up * 0.01f; // 每次读 + 写，2 次 Vector3 拷贝 } // ✅ 缓存到局部变量 Vector3 pos = transform.position; // 1 次读取 for (int i = 0; i < 100; i++) { pos += Vector3.up * 0.01f; // 栈上操作，无 GC } transform.position = pos; // 1 次写回

3.4 防御性拷贝

readonly struct的属性访问可能触发防御性拷贝（defensive copy）。这是 C# 编译器在readonly struct上调用非readonly方法时生成的隐式拷贝：

public readonly struct MyData { public int Value { get; } public MyData(int v) { Value = v; } // ❌ 没有声明为 readonly 的方法 public void SetToZero() { // Value = 0; // 编译错误！readonly struct 不能修改 } } MyData data = new MyData(42); // 编译器生成防御性拷贝： data.SetToZero(); // 实际执行：new MyData(42).SetToZero(); // data 本身没有被修改，修改的是临时拷贝 // ✅ 将方法声明为 readonly public readonly struct MyData { public int Value { get; } public MyData(int v) { Value = v; } public void SetToZero() // 编译器保证不修改 this { // 不能修改任何字段 } }

防御性拷贝虽然发生在栈上（不产生 GC 分配），但对大struct的拷贝代价仍然显著。一个 64 字节的struct的防御性拷贝需要 4 条movaps指令，约 4 纳秒。在热路径中频繁触发时，累积开销不容忽视。

解决方案：所有readonly struct的方法都应该声明为readonly，告诉编译器不需要生成防御性拷贝。

四、struct 的装箱（Boxing）

4.1 装箱的 GC 影响

struct装箱是最常见的意外 GC 分配来源之一。当struct被转换为object、interface类型、或作为泛型参数 T 且 T 被约束为class时，会发生装箱：

public struct Point { public int X, Y; } Point p = new Point { X = 1, Y = 2 }; // ❌ 装箱：struct 复制到堆上，产生 GC 对象 object obj = p; // 堆上分配 ~16 字节（对象头 + 8 字节数据） Console.WriteLine(p); // 隐式装箱到 IFormattable IEnumerable<Point> list = new[] { p }; // 装箱到 interface // ✅ 避免装箱 Point p2 = p; // 栈上拷贝，零 GC string s = $"{p.X},{p.Y}"; // 使用字段直接格式化，不装箱 struct

装箱的 GC 代价：

1. 堆分配：装箱在堆上分配一个新对象，大小为sizeof(struct) + 8（对象头）。
2. 数据拷贝：struct的字段被复制到堆对象中。
3. 指针解引用：后续访问需要通过指针解引用回到堆上。

在热路径中，意外的装箱可能成为 GC 分配的主要来源。例如，将struct传入Debug.Log(object)会装箱；将struct存入ArrayList（非泛型集合）会装箱。

4.2 泛型中的装箱

泛型是避免装箱的关键工具，但使用不当也会产生装箱：

public struct Point { public int X, Y; } // ✅ 泛型方法：T 为 struct 时不装箱 void Process<T>(T value) where T : struct { // T 是值类型时，value 在栈上，无装箱 } Process(new Point { X = 1, Y = 2 }); // 零装箱 // ❌ 无约束泛型：T 为 struct 时可能装箱 void ProcessUnconstrained<T>(T value) { // 如果 T 是值类型，调用 ToString() 可能装箱 // 因为 JIT 不知道 T 是否有虚方法实现 Console.WriteLine(value); // 可能装箱到 IFormattable } // ✅ 使用 where T : struct 约束 void ProcessStruct<T>(T value) where T : struct { // JIT 知道 T 是值类型，可以优化掉装箱 }

在 .NET 中，泛型方法在T为引用类型和值类型时会分别生成代码实例。当T为值类型时，参数直接在栈上，不涉及装箱。但当调用ToString()、GetHashCode()等虚方法时，JIT 可能生成装箱代码来调用基类实现——这就是为什么where T : struct约束不能完全消除装箱。

4.3 interface 装箱

struct实现interface时，通过 interface 引用调用方法会装箱：

public struct Point : IFormattable { public int X, Y; public string ToString(string? format, IFormatProvider? provider) { return $"({X}, {Y})"; } } Point p = new Point { X = 1, Y = 2 }; // ❌ 通过 interface 引用调用 → 装箱 IFormattable fmt = p; // 装箱 fmt.ToString(null); // 通过 interface 调用 // ✅ 直接调用 → 不装箱 p.ToString(null); // 直接调用，无装箱

这个陷阱在 LINQ 和集合操作中特别常见。List<IFormattable>中的每个Point元素都会装箱，因为List<T>存储的是IFormattable引用，而IFormattable是引用类型。

五、readonly struct 与 ref struct

5.1 readonly struct 的语义

readonly struct是 C# 7.2 引入的特性，保证struct实例在其生命周期内不被修改：

public readonly struct Vector3 { public readonly float X, Y, Z; public Vector3(float x, float y, float z) { X = x; Y = y; Z = z; } // ✅ readonly 方法：保证不修改 this public Vector3 Normalized() readonly { float len = Magnitude(); return new Vector3(X / len, Y / len, Z / len); } public float Magnitude() readonly { return Mathf.Sqrt(X * X + Y * Y + Z * Z); } }

readonly struct的优势：

1. 编译器保证不可变：任何尝试修改this的操作都会编译错误。
2. 消除防御性拷贝：readonly方法不会触发防御性拷贝。
3. 线程安全：不可变对象天然线程安全。
4. 可以作为readonly字段：readonly Vector3 _position;

readonly struct的限制：

1. 所有字段必须是readonly：不能有可写的实例字段。
2. 不能有非readonly方法：所有方法必须声明为readonly。
3. 不能作为class的可变字段：class中的readonly struct字段不能被修改（但可以通过ref访问器修改）。

5.2 ref struct 的限制

ref struct是 C# 7.2 引入的特性，保证struct永远在栈上，不会逃逸到堆上：

public ref struct SpanLike<T> { private T[] _array; private int _index; public SpanLike(T[] array) { _array = array; _index = 0; } public ref T this[int index] => ref _array[_index + index]; } // ref struct 的限制： // 1. 不能作为 class 的字段 // 2. 不能被装箱 // 3. 不能作为 async 方法的局部变量 // 4. 不能被捕获在闭包中 // 5. 不能实现接口（C# 11 之前） // ❌ 编译错误：ref struct 不能作为字段 public class BadClass { // SpanLike<int> _data; // 编译错误！ } // ❌ 编译错误：ref struct 不能在 async 方法中 public async Task BadAsync() { // SpanLike<int> data = new SpanLike<int>(Array.Empty<int>()); // 编译错误！ await Task.CompletedTask; } // ✅ 正确用法：同步方法中 public void GoodSync(SpanLike<int> data) { data[0] = 42; // OK }

ref struct的核心价值是零分配保证——编译器保证它永远不会被分配到堆上。这是Span<T>和MemoryManager<T>等类型的基础。

六、struct 大小的最佳实践

6.1 16 字节原则

业界普遍建议：struct大小不超过 16 字节。超过 16 字节时，拷贝开销开始显著，class可能更合适。

这个建议的依据：

1. L1 缓存行大小：现代 CPU 的 L1 缓存行为 64 字节。16 字节的struct可以一个缓存行容纳 4 个实例，缓存利用率高。
2. 寄存器拷贝：x86-64 的 SSE 寄存器为 128 位（16 字节），16 字节的struct只需一条movaps指令即可完成拷贝。
3. 方法参数传递：x86-64 调用约定前 6 个参数通过寄存器传递（RCX, RDX, R8, R9, XMM0, XMM1）。16 字节的struct可以放入 2 个 XMM 寄存器，无需压栈。

// ✅ 16 字节以内：推荐 struct public struct Color { public byte R, G, B, A; } // 4 字节 public struct Vector2 { public float X, Y; } // 8 字节 public struct Vector3 { public float X, Y, Z; } // 12 字节 public struct Vector4 { public float X, Y, Z, W; } // 16 字节 // ⚠️ 16-64 字节：谨慎使用 struct，考虑 ref 参数 public struct PlayerStats { /* ... */ } // 假设 32 字节 // 传递时使用 ref PlayerStats // ❌ 超过 64 字节：使用 class public struct LargeData { /* ... */ } // 假设 128 字节 // 改用 class LargeData

6.2 字段排列优化

对于必须大于 16 字节的struct，通过字段排列可以减少内存占用：

// ❌ 字段排列不佳：24 字节 public struct BadPacked { public byte Type; // offset 0, 1 byte + 7 字节填充 public long Id; // offset 8, 8 bytes public byte Flags; // offset 16, 1 byte + 7 字节填充 // Total: 24 bytes } // ✅ 字段排列优化：16 字节 public struct GoodPacked { public long Id; // offset 0, 8 bytes (最大字段放前面) public byte Type; // offset 8, 1 byte public byte Flags; // offset 9, 1 byte // padding: // offset 10, 6 bytes // Total: 16 bytes }

七、struct 与 class 的选择决策树

需要创建对象？ │ ├─ 需要多态/继承？ │ └─ Yes → class │ ├─ 需要作为 interface 实现？ │ └─ Yes → class（或 struct + 接受 interface 装箱） │ ├─ 需要在多个地方共享引用？ │ └─ Yes → class │ ├─ 大小 > 64 字节？ │ └─ Yes → class │ ├─ 需要不可变性/线程安全？ │ └─ Yes → readonly struct（或 class + 不可变设计） │ ├─ 频繁作为方法参数传递？ │ ├─ struct 大小 ≤ 16 字节 → struct │ └─ struct 大小 > 16 字节 → class 或 ref 参数 │ └─ 存储在集合中（List<T>, Dictionary<K,V>）？ ├─ T 为 struct → 元素内嵌，无额外装箱（但集合本身分配在堆上） └─ T 为 class → 每个元素独立分配

八、性能基准

8.1 struct vs class 分配对比

// struct: PointS { public float X, Y, Z; } // 12 bytes // class: PointC { public float X, Y, Z; } // 12 + 16(header) = 28 bytes // 100 万次操作对比： // struct 数组: 连续内存, 1 次分配 PointS[] arrS = new PointS[1000000]; // 12MB, 1 次 GC 分配 // class 数组: 100 万次分配 + 28MB + 碎片 PointC[] arrC = new PointC[1000000]; // 引用数组 8MB + 100 万次对象分配 28MB

8.2 拷贝开销基准

九、Unity 中的 struct 实践

9.1 Unity 内置 struct

Unity 大量使用struct作为核心数据类型：

// Unity 内置 struct（全部 ≤ 16 字节） Vector3 position; // 12 字节 Quaternion rotation; // 16 字节 Color color; // 16 字节 (RGBA 各 4 字节 float) Bounds bounds; // 24 字节 (center 12 + extents 12) Ray ray; // 24 字节 (origin 12 + direction 12) Matrix4x4 matrix; // 64 字节

这些struct的设计遵循了 16 字节原则（除了Matrix4x4和Bounds），在性能和功能之间取得了良好平衡。

9.2 自定义 struct 的最佳实践

// ✅ 好的 struct 设计 public readonly struct GameState { public readonly int Score; public readonly int Level; public readonly float TimeRemaining; public GameState(int score, int level, float time) { Score = score; Level = level; TimeRemaining = time; } // 所有方法都是 readonly public GameState WithScore(int newScore) readonly { return new GameState(newScore, Level, TimeRemaining); } } // ❌ 不好的 struct 设计 public struct BadGameState { public int Score; // 可变的 public 字段 public List<string> Logs; // 引用类型字段！ public string Name; // 引用类型字段！ // 大小: 12 + 8 + 8 = 28 字节（但实际引用指向堆对象） }

十、常见误区

10.1 "struct 永远不会产生 GC 分配"

这是最常见的误区。struct在以下情况会产生 GC 分配：

1. 装箱：转换为object或interface时。
2. 作为 class 的字段：class的字段中存储的struct随class一起在堆上分配。
3. 存储在List<T>等集合中：List<T>的内部数组在堆上，struct元素内嵌在数组中。
4. 包含引用类型字段：struct中的string、class字段指向堆对象。

public struct BadStruct { public string Name; // 引用类型！struct 在栈上但 Name 指向堆 public int Value; } BadStruct s = new BadStruct { Name = "Hello", Value = 42 }; // s 本身在栈上（16 字节），但 s.Name 指向堆上的 string 对象 // 修改 Name 不会影响原 string（string 不可变），但引用指向堆

10.2 "struct 总是比 class 快"

struct在以下情况下可能比class慢：

1. 大 struct 的拷贝：64 字节以上的struct拷贝开销可能超过引用传递。
2. 方法参数传递：频繁传递大struct作为参数，拷贝开销累积。
3. 属性访问：返回struct的属性每次访问都产生拷贝。
4. 装箱：struct装箱的开销大于class的引用传递。

10.3 "struct 不能包含引用类型"

struct可以包含引用类型字段，但这会削弱struct的零 GC 优势：

public struct MixedStruct { public int Value; // 值类型，内嵌 public string Name; // 引用类型，指向堆对象 public MyClass Obj; // 引用类型，指向堆对象 } MixedStruct s = new MixedStruct(); // s 本身在栈上（8 + 8 + 8 = 24 字节，64 位平台） // 但 s.Name 和 s.Obj 指向堆上的对象

这种混合结构在语义上接近class，但保留了值拷贝语义——每次赋值拷贝整个struct（包括引用字段的值，即指针值），但引用的目标对象不被拷贝。

十一、总结与实践建议

11.1 核心要点回顾

struct的 GC 优化价值体现在：

1. 栈上分配零 GC：局部struct变量在栈上分配，随函数返回自动释放。
2. 数组内嵌零额外分配：struct[]的元素内嵌在数组中，只需一次数组分配。
3. 值拷贝语义：每次赋值和参数传递产生完整拷贝，小struct代价极低。
4. readonly struct 消除防御性拷贝：readonly方法不触发隐式拷贝。
5. ref struct 零逃逸保证：编译器保证ref struct永远在栈上。

11.2 实践建议

基于对struct内存模型的理解，以下是针对 C# 开发者的实践建议：

1. 16 字节原则：struct大小不超过 16 字节。超过时用class或ref参数。
2. 字段排列优化：大字段放前面，减少对齐填充。
3. 使用 readonly struct：不可变struct声明为readonly struct，方法声明为readonly。
4. 避免 struct 中的引用类型：string、class字段会削弱零 GC 优势。
5. ref/in 参数优化：大于 16 字节的struct传递时使用ref或in。
6. 缓存属性返回值：返回struct的属性值缓存到局部变量，避免重复拷贝。
7. 警惕装箱：避免将struct转换为object或interface。
8. struct 数组优于 class 数组：对于需要存储大量同质数据的场景，struct[]在内存和 GC 上都有显著优势。

11.3 struct 使用决策速查表

十二、深入：struct 在 JIT 中的优化

12.1 寄存器分配

JIT 编译器会尝试将小struct的字段分配到寄存器中，避免内存访问：

public struct Point { public int X, Y; } // 8 字节 Point Add(Point a, Point b) { return new Point { X = a.X + b.X, Y = a.Y + b.Y }; }

在 x86-64 上，JIT 可能生成如下优化：

; a 在 RCX, b 在 RDX mov eax, [rcx] ; a.X add eax, [rdx] ; + b.X mov edx, [rcx+4] ; a.Y add edx, [rdx] ; + b.Y ; 结果在 EAX:EDX，直接返回

这种优化使得小struct的操作几乎等同于内联的寄存器操作，延迟低于 1 纳秒。

12.2 结构化逃逸分析

JIT 编译器执行逃逸分析（escape analysis），确定struct是否"逃逸"到堆上：

• 不逃逸：struct仅在函数栈帧内使用 → 完全在栈上分配，可能完全优化掉（寄存器化）。
• 逃逸：struct被装箱、存储为class字段、或通过ref返回 → 需要在堆上分配或保持栈上存活。

// 不逃逸：JIT 可能完全优化掉 struct 分配 Point MakePoint() { Point p = new Point { X = 1, Y = 2 }; return p; // 返回值直接放入寄存器，无栈上分配 } // 逃逸：struct 必须存储在堆上 Point MakePointEscaping() { Point p = new Point { X = 1, Y = 2 }; _globalPoint = p; // 存储为 class 字段 → 逃逸 return p; }

逃逸分析是 JIT 优化的核心手段之一。理解哪些操作会导致逃逸，有助于写出更高效的代码。

12.3 结构内联（Struct Inlining）

对于非常小的struct（如 2-4 字节的Point2D），JIT 可能将其"内联"到使用它的上下文中：

public struct Point2D { public int X, Y; } // 8 字节 public class Shape { public Point2D Position; // struct 字段 public int Size; } Shape s = new Shape(); s.Position.X = 10; // JIT 可能将 Position 内联为直接内存访问

在 .NET 5+ 中，JIT 的结构内联优化更加激进，可以将嵌套的小struct完全内联为基本类型的字段序列。

十三、与 Unity GC 的对比

13.1 Unity 的 struct 处理

Unity 的 Mono/IL2CPP 后端对struct的处理与 .NET Core 略有不同：

IL2CPP 将 C#struct转换为 C 结构体，在栈上分配时直接对应 C 栈变量。这意味着 IL2CPP 后端对小struct的优化可能比 Mono 更好（直接映射为 C 变量），但也可能更差（C 编译器优化能力有限）。

13.2 Unity 中的 struct 陷阱

Unity 中struct的 GC 陷阱与标准 C# 类似，但有额外的 Unity 特定陷阱：

1. GetComponent<T>()返回T时：T为struct时返回拷贝，不影响 GC。
2. SendMessage传递struct：SendMessage通过反射调用，struct参数会被装箱。
3. Coroutine中传递struct：IEnumerator实现会装箱struct局部变量。

// ❌ SendMessage 装箱 struct 参数 void OnDamage(int damage) { } this.SendMessage("OnDamage", new Vector3(1, 0, 0)); // Vector3 装箱！ // ✅ 使用委托替代 Action<Vector3> onDamage; onDamage += OnDamage; onDamage.Invoke(Vector3.right); // 零装箱

十四、结语

struct是 C# 零 GC 编程的基石。它的价值不在于"完全消除 GC"，而在于"在正确的场景使用正确的类型"。小struct在栈上分配、缓存友好、拷贝代价极低；大struct或包含引用类型的struct可能比class更差。

理解struct的内存布局、拷贝语义和装箱机制，是写出高效 C# 代码的基础。在下一章中，我们将深入Span<T>和stackalloc（08-07），看看如何利用ref struct实现真正的零分配编程。