C#类型选型：enum、struct与class的设计差异与性能实践

这篇总结最早是我整理给组里新人的内部资料，本来只想写一页速查表，结果越写越长。C# 里的 enum、struct、class 这三个关键字，几乎所有入门教材都会讲，但大部分教材只讲了“怎么定义”，没讲清楚它们背后的设计含义——什么时候该用哪个、选错了会付出什么代价。这个问题我觉得值得摊开来聊一聊。

写代码这几年，尤其是做上位机采集、TCP 数据解析这类对分配频率敏感的程序时，我对类型选择的体会特别深。很多人一开始觉得 enum、struct、class 只是“定义类型的不同写法”，其实它们决定了数据的存储位置、复制方式、生命周期，甚至直接影响 GC 压力和程序卡顿。今天这篇不是照着 MSDN 念定义，而是按我实际开发中的理解，把三者的差异、原理、坑和选型思路完整过一遍。

1. 这三者不是同类语法，是三种数据策略

1.1 一句话把三者的定位分开

很多新手把 enum、struct、class 放在一起背，觉得都是“定义一个自定义类型”。但它们的核心定位完全不同：

• enum 的本质是一组有名字的整数常量，它不存复杂数据，只是给数值起个可读的名字。
• struct 定义的是一个“值”，这个值直接内联在变量所在的位置里。你把一个 struct 变量赋给另一个变量，就是把里面所有字段完整复制一份，得到的是两份独立数据。
• class 定义的是一个“对象”，变量里实际存的是一个指向托管堆的引用。你复制这个变量，只是复制了门牌号，两个变量指向的还是同一个对象。

这三者看似只是语法关键字，实际上背后是三种完全不同的数据策略：常量标签、值语义、引用语义。理解到这一层，才能解释为什么有些代码用 class 性能差，为什么有些 struct 改了字段没生效，为什么枚举不能防住非法值。

1.2 引用像门牌号，值像存放在身上的现金

用一个生活化的类比。class 变量就像一张写有地址的纸条，如果你把纸条抄一份给别人，大家去的是同一个房子，任何一个人往房子里搬东西，其他人立刻能看到变化。struct 变量更像是你钱包里的一张现金，你递给别人一张等额的钱，对方花掉不影响你手里的钱，两张钱是完全独立的个体。

所以看一段代码时，先问一个问题：我需要大家共享同一个东西，还是每个人各拿一份？这个问题的答案基本就决定了该用 class 还是 struct。业务里大多数模型需要“共享身份”，比如设备对象、用户会话、配置信息，天然是 class。而数值计算中的坐标、采样点、格式化之后的一小段临时数据，往往是“各算各的”，更适合 struct。

1.3 一张速查表看清基础差异

为了方便后面展开，我先放一张总表，后面每个部分都会围绕其中某些行再展开。

看到这里你应该就能理解，为什么“键盘敲得快”不代表“类型选得对”。这三类选择背后，是一种关于数据存储和共享策略的设计权衡。

2. enum：有名字的整数，但不是安全类型

2.1 enum 的底层规则比你以为的简单

enum 在底层就是一个整数，默认情况下类型是 int。你可以显式指定底层类型，byte、sbyte、short、ushort、int、uint、long、ulong 都行。协议解析场景我喜欢把枚举底层指定为 byte，配合报文里的单字节协议号，能省空间也更直观。

csharp复制public enum CommandCode : byte
{
    Heartbeat = 0x01,
    ReadRegister = 0x02,
    WriteRegister = 0x03
}

定义成员时如果不指定数值，编译器会从 0 开始逐个加一。很多老代码习惯只写名字不写值，比如：

csharp复制public enum OrderStatus
{
    Created,     // 0
    Paid,        // 1
    Shipped,     // 2
    Completed    // 3
}

这种方式写在只增不改的场合还好，一旦将来在中间某个位置插入了新成员，后面所有成员的数值都会变化。你自己代码里可能是同步的，但如果有数据已经按旧版本持久化到数据库或配置文件里，新旧对不上就是线上事故。所以我实际写的时候，几乎总是给每个枚举显式赋一个独立的常量值，宁可多写几行，也不把顺序当作语义。

2.2 需要组合状态的枚举，用 [Flags] 更好维护

当你要表达“多个选项同时成立”时，例如上位机里一个设备的采集通道可能同时启用了温度、湿度和电压，就不用定义一堆布尔字段，可以直接用一个位标记枚举。

csharp复制[Flags]
public enum ChannelMask
{
    None = 0,
    Temperature = 1 << 0,
    Humidity = 1 << 1,
    Voltage = 1 << 2,
    All = Temperature | Humidity | Voltage
}

这里有几个要点。第一个，位标记枚举的值必须是 2 的整数幂，否则“或”出来的结果无法唯一反推。第二个，0 值成员通常叫 None，表示“什么都没有”。第三个，判断是否包含某个标记时，在老版本 C# 里常见写法是 (mask & ChannelMask.Temperature) == ChannelMask.Temperature，后来有了 Enum.HasFlag 方法，阅读起来更直白。

csharp复制if (mask.HasFlag(ChannelMask.Temperature))
{
    // 启用温度采集
}

但如果你写的是高性能循环里的频密判断，HasFlag 在早期的 .NET Framework 实现里遇到过装箱和反射开销的问题，现代 .NET 版本有改进，我在追求极致吞吐率的场合仍然直接写位运算，读者一眼就知道在做什么，也不依赖运行时优化。

2.3 枚举的三个经典坑

第一个坑很多人都没见过，但很容易踩到：枚举并不能限制变量只能是已定义成员。举个例子。

csharp复制public enum Color
{
    Red,
    Green,
    Blue
}

Color c = (Color)100;  // 完全合法，不会抛异常

枚举只是一个强类型的整数包装，编译器在运行期不会校验你有没有越界。如果你从 TCP 报文里直接强转出一个枚举值，后面用 switch 分支没覆盖到，代码会静默走向 default，错误就被掩盖了。所以涉及外部输入时，最好加一道校验：

csharp复制if (Enum.IsDefined(typeof(Color), rawValue))
{
    Color c = (Color)rawValue;
}
else
{
    // 记录异常报文并走错误处理
}

Enum.IsDefined 的实现效率不高，底层走反射，不适合在超高频循环里对每个报文都查一次，但作为入口处的防御性校验是值得的。对于按位组合的 [Flags] 枚举，IsDefined 根本没法用，因为组合值不在命名列表里，这种情况要自行校验“哪些位是允许的”。

第二个坑是 Enum.ToString() 和 Enum.Parse 都不快。ToString() 会把枚举值映射为名称，底层涉及名称查表，性能远不如整数比较。如果你要在日志系统里大量打印枚举名，尤其是热路径里的诊断日志，最好提前把常用值缓存在静态字典里，或者干脆输出数值。枚举名称是给人看的，机器日志优先考虑数值的稳定和低成本。

第三个坑是枚举适合表达“相对稳定”的集合，不适合频繁增删。很多产品迭代过程中，枚举成员动不动就加，结果每个服务端、客户端、数据库映射层都要同步，漏一个就崩。如果状态种类需要在运行期动态扩展，我会考虑用静态类加只读字段配合字符串或 GUID，而不是继续往 enum 里塞成员。这不是说 enum 不好，而是它本身就是为编译期固定集合设计的工具。

3. struct：小而快的值类型，但别见“值类型”就冲

3.1 复制语义让每个变量保持独立

struct 最核心的特征是复制语义。定义一个二维坐标结构，再做一次赋值：

csharp复制public struct Point
{
    public int X;
    public int Y;
}

Point p1 = new Point { X = 1, Y = 2 };
Point p2 = p1;
p2.X = 100;

Console.WriteLine(p1.X); // 输出 1，p1 完全不受影响

这段代码能解释很多“莫名其妙”的现象。你有没有遇到过，把一个 struct 对象塞进 List，然后尝试改 list[0].X = 10，结果编译直接报错？原因就是 List 的索引器返回的是内部数组元素的副本，如果你改的是副本，写回去没有意义，编译器直接禁止这种操作。数组反而允许，因为数组索引返回的是元素的引用位置：

csharp复制Point[] points = new Point[10];
points[0].X = 10; // 允许，直接修改数组元素本身

这也是我在大量数据场景优先用 struct 数组而不是 List 的原因之一，后者在高频随机读写时会平白多出很多边界逻辑和无法直接 ref 修改的别扭体验。

3.2 struct 会在哪里悄悄装箱

struct 是值类型，正常存储在变量自身位置，不产生 GC 对象。但一旦你把它当作接口或 object 使用，装箱就发生了。所谓装箱，就是运行时把结构体的内容复制一份到托管堆上，外面包一个对象头，变量引用的是这个“盒子”。

csharp复制Point p = new Point { X = 1, Y = 2 };
object o = p;   // 装箱：堆上生成新对象，拷贝 p 的内容
Point q = (Point)o; // 拆箱：再从堆对象中拷贝回来

这段代码里有个很微妙的地方：你转成 object 后，修改那个“盒子”里的内容，不会影响原变量 p。因为装箱本身就是拷贝。真正生产环境里更隐蔽的是接口装箱。

csharp复制public struct Point : IComparable
{
    public int X;
    public int Y;

    public int CompareTo(object obj)
    {
        // 实现
    }
}

IComparable comparable = p; // 这里也装箱了

当一个 struct 实现了接口，你却把它的实例赋给接口变量时，为了满足引用类型的接口模型，运行时必须装箱。所以如果你要定义一个 struct 并且希望它在集合里高效比较，最佳实践是同时实现泛型版本的 IEquatable<T> 与 IComparable<T>，再配合泛型约束使用。例如 Dictionary<Point, int> 如果 Point 只实现了非泛型的 Equals，内部调用时很可能发生装箱；而实现 IEquatable<Point> 并提供 where T : IEquatable<T> 的上下文，就可以让 JIT 为具体值类型生成特化代码，从而避免装箱。

还有一类更常见的装箱来自 Console.WriteLine 和 string.Format。你在热循环里拼接大量数值时，如果直接 $"{point}"，而 Point 没实现 ISpanFormattable 这类高性能格式化接口，就可能触发额外的转换开销。日志里偶尔用无所谓，但百万级采样点的日志输出就要留心。

3.3 现代 C# 给 struct 上的几道保险

老一代 C# 的 struct 几乎是“裸奔”的状态，谁都能改字段，一不小心就会遇到修改副本而非原对象的诡异问题。现代 C# 提供了多个约束机制，最值得关注的是 readonly struct、readonly 成员和 ref struct。

readonly struct 表示这个结构体所有实例字段都是只读的，构造完成后不能再改。用它建模坐标点、采样值这类“一个不可变值”非常合适。

csharp复制public readonly struct Sample
{
    public double Value { get; }
    public long Timestamp { get; }

    public Sample(double value, long timestamp)
    {
        Value = value;
        Timestamp = timestamp;
    }
}

readonly 修饰最大的价值是防止“拷贝陷阱”。一个可变 struct 如果作为某个类的 readonly 字段，外部代码想改字段里的某个成员时，编译器会基于“警惕修改副本”的原则拒绝编译，让你意识到这里可能有语义问题。

ref struct 则是更严格的约束：它只能存活在栈上，不能装箱，不能作为 class 的字段，不能被 async 方法捕获。典型例子是 Span<T>。这样设计是为了保证这块内存不会被 GC 移动，也不会有逃逸风险，是高性能数组操作和安全之间的一种平衡。

C# 10 之后又引入了 record struct，它让值类型自动获得值相等性、with 表达式和解构支持，适合做数据传输对象。注意别把 record struct 和 record class 搞混：前者仍是值类型，后者是引用类型，两者在赋值和相等判断上完全不同。

3.4 用 struct 之前，先过一遍检查清单

微软的性能文档给过一组判断准则，我根据自己踩坑经历加了注释，整理成下面这个清单。不是说所有条件必须全部满足才能用，但如果你发现当前类型不满足大部分条件，最好回到 class。

• 逻辑上表示的是单个值，类似一个原始类型。比如坐标点、采样值、时间区间。
• 实例尺寸很小。以前的建议是 16 字节以内，现代 64 位环境下 24 字节也常见，但“尽量小”仍然正确。
• 不可变。如果未来很可能需要频繁修改，class 会省去大量拷贝困惑。
• 很少需要装箱。如果需要频繁放进 object、接口列表，struct 的优势会被装箱抵消。
• 你希望它作为数组元素时能连续紧凑存放，以提升内存局部性和缓存命中率。

我可以直接说：满足这些条件时，struct 能带来肉眼可见的性能提升，尤其是以数组形式存储海量小对象时。反过来，一个超过几十字节的可变结构体硬要用 struct，每次赋值都是成片内存拷贝，性能可能比 class 还差，代码也更难维护。

4. class：虽然人人会用，但它的设计语义常被低估

4.1 class 的“共享身份”在领域建模里无法替代

class 是引用类型，天然适合表达那些在系统中拥有独立身份、需要被多处共享和修改的对象。比如一个设备连接对象，上位机界面、数据采集线程、状态监控模块都想引用到同一个实例，任何一个模块改了连接状态，其他模块都能立刻看到。如果强行把所有业务实体都用 struct 建模，你将面临一个噩梦：每传一次都复制一份，改完这个副本另一个模块看不到，逻辑彻底乱套。

所以说 class 不只是一个“语法上能继承”的类型，它承载的是对象身份和可变共享状态。对大多数业务项目来说，核心模型用 class 是默认选择，因为业务规则关心的往往是“这本订单现在到哪一步了”“这个用户会话是否还活着”这类跨模块状态一致性问题。

另一个容易被忽略的是 null 语义。class 变量可以没有指向任何对象，这是领域建模中的常见状态：一个尚未配置的通道、一个尚未连接的设备、一个还未下发的命令。struct 没有这种直观的“空”概念，它的默认值是所有字段归零，你要额外用 MyStruct? 才能表达“没值”，这层包装本身也带来心智负担。

4.2 为什么 C# 默认推荐 class，而不是“能省则省”

很多从 C++ 转来的开发者会问：C++ 里类对象默认放栈上性能很好，C# 为什么老是鼓励用 class？如果把所有小对象都改成 struct 是不是更快？

真实情况是，C# 的默认选择经过了很多性能与生产力的权衡。第一，托管堆分配本身并不慢，在年轻代上它几乎等价于指针移动，比很多人想象中廉价。第二，class 传参时只复制一个 8 字节的引用（64 位下），比起复制几十上百字节的 struct，调用成本更低。第三，大多数业务对象生命周期长短不一、结构复杂，用 struct 做频繁复制反而是一种浪费。

class 真正的代价集中在两点：GC 回收压力和内存分散不连续。当一个程序在短时间内创建海量短命小对象，GC 年轻代会频繁触发，造成卡顿；当大量对象分散在堆上，遍历它们时缓存命中率差，速度反而慢。这个问题我在第 5 节的案例里会详细展开。这里先记住一个结论：class 是业务建模的“默认省心选项”，struct 是性能关键点的“手动优化选项”，不要本末倒置。

4.3 给 class 增加“告别版”和“等价版”：sealed 与 record

现代 C# 里 class 也不是毫无变化。两个值得关注的进化方向是 sealed 和 record。

sealed class 禁止其他类继承它。很多开发者以为这只是“为了安全”，其实对 JIT 优化有很大帮助。当一个方法收到一个 sealed 类型的引用并调用它的虚方法时，JIT 能更容易判断没有其他子类会覆盖该方法，从而去做去虚拟化甚至内联优化。所以如果你设计的是内部工具类、领域模型里不会扩展的叶子对象，别犹豫，直接标 sealed。

record class 则在 C# 9 引入了一种类类型快速建模方式：

csharp复制public record DeviceConfig(string DeviceName, int BaudRate, bool EnableLog);

它依然是引用类型、依然有继承能力，但编译器自动帮你实现了基于属性的值相等性，还提供 with 表达式做非破坏性更新。在配置对象、DTO 这些“不太需要可变性但需要易于比较”的场景，比手写一堆重载舒服多了。注意 record class 是引用类型，record struct 才是值类型，两者本质仍受制于我们前面讨论的值引用语义，不能被语法糖弄混。

5. 从一次采集模块的改造看实际选型

5.1 最初的设计：万物皆 class，方便是方便，GC 扛不住

之前我优化过一个采集模块。它需要从 TCP 流里解析设备上报的采样点，每秒钟大约产生十几万个采样点，每个点包含通道号、采样值和时间戳。最初版本的内层模型是这样写的：

csharp复制public class Sample
{
    public int Channel { get; set; }
    public double Value { get; set; }
    public long Timestamp { get; set; }
}

public class Acquirer
{
    private readonly List<Sample> _batch = new List<Sample>(4096);

    public void AddSample(int channel, double value, long timestamp)
    {
        _batch.Add(new Sample
        {
            Channel = channel,
            Value = value,
            Timestamp = timestamp
        });
    }
}

这段代码本身没有任何逻辑错误。采集、展板显示、历史存储全部依赖这个类。问题出在压力测试时：每秒钟十几万个 new Sample()，年轻代里很快就堆满了等待回收的短命对象，GC 频率肉眼可见地升高，采集线程出现周期性的停顿。我抓了一次分配 profiling，发现绝大部分分配都集中在 Sample 对象上。

5.2 拆分层级：业务对象该用 class 继续用，内层数据换成 struct

我做的第一件事不是把代码中所有 Sample 换成 struct 了事，而是先想清楚，这些 Sample 到底是“有身份的业务实体”还是“临时承载数值的值”。分析之后发现，Sample 从诞生到写入历史队列，全程没有人在中途修改它，也没有多个模块要共享同一个实例，它本质就是一组数值的打包，完全符合“不可变、表示一个值、小型”的特征。

于是改造方案非常清晰：设备、连接、通道配置这些有身份有状态的东西继续是 class；而采集过程中瞬时产生的批内数据点，改成 readonly struct，并直接放进结构体数组：

csharp复制public readonly struct Sample
{
    public int Channel { get; }
    public double Value { get; }
    public long Timestamp { get; }

    public Sample(int channel, double value, long timestamp)
    {
        Channel = channel;
        Value = value;
        Timestamp = timestamp;
    }
}

批处理逻辑也调整成批量追加：

csharp复制private Sample[] _batch = new Sample[4096];
private int _count;

public void AddSample(int channel, double value, long timestamp)
{
    _batch[_count++] = new Sample(channel, value, timestamp);
    if (_count == _batch.Length)
    {
        FlushBatch(); // 批满送下游
    }
}

采集点本身已经是纯值，永久共享身份根本没有意义。改造后采样点不再分配独立堆对象，Sample[] 是一次性分配的连续内存块，后续每个元素只是按位拷贝进去。GC 压力几乎是数量级下降，因为每批只有一个数组对象需要管理，而不是十几万个独立小对象。

5.3 这件事给我的选型教训

这次改造让我真正理解了“内层用 struct，外层用 class”的分工价值。采集链路的最内层是高频、短命、无共享诉求的纯数据，适合 struct；而设备对象这种跨线程共享、需要身份协作的实体，如果强行改成 struct，每次异步回调都复制一份连接状态，才是真正的灾难。

所以我的选型逻辑从来不是“性能慢就换 struct”，而是先判断数据的本质：它到底是“一个值”，还是“一个对象”？这个判断做完，再考虑性能。class 和 struct 之间没有谁绝对更好，一旦把它们的语义用错了方向，要么业务复杂度爆炸，要么 GC 压力爆炸。

6. 常见误区和排查速查

6.1 先列出几个高频误区

6.2 排查问题时的定位思路

如果你正在代码里遇到和值类型引用类型相关的诡异问题，按这个顺序走一遍基本能找到方向。

第一步，确认变量赋值后，你修改新变量到底想不想影响旧变量。想影响就用 class，不想影响且数据结构小就用 struct。混用两种语义是很多隐蔽 bug 的来源。

第二步，确认有没有发生装箱。可以对目标代码做一次分配 profiling，看生成的对象里有没有非预期的盒子。重点检查：struct 是否赋给了 object、接口变量或非泛型集合，是否在调用 string.Format、Console.WriteLine、ArrayList.Add。

第三步，确认 struct 是不是可变类型，且是否出现过“改了没生效”的现象。如果答案都是肯定的，优先改成 readonly struct，或把修改点改成数组元素的直接操作。

第四步，确认性能瓶颈是否来自海量短命 class 对象。如果是，内层纯数据对象改成 struct 数组；外层有状态业务对象保持 class。

6.3 面试里最常被追问的题目，顺便整理成自测

面试官喜欢问“什么时候用 struct，什么时候用 class”，其实背后考察的是你对值类型和引用类型语义的理解深度。你可以用这几个问题快速自测：

• 你能解释默认传参时 struct 和 class 的区别吗？遇到一个超大的 struct 时，传参为什么会很慢？
• 两个 struct 变量做 == 比较，和两个 class 变量做 == 比较，默认行为有什么不同？什么时候需要自己重写 Equal？
• Nullable<T> 本质上是什么类型？bool? 和 bool 有什么区别？
• 把一个 struct 存入 ArrayList 再取出来，中间发生了什么？
• 为什么 readonly struct 能让代码更安全？你以前遇到过可变 struct 引起的问题吗？
• enum 的底层可以设置为 byte，这样做在协议解析里有什么好处？

这套问题没有标准答案八股文，把它们结合到真实代码场景中说出来，通常要比背定义有说服力得多。

最后说一点长期养成的习惯。我写类型定义之前，总会先下意识问自己：这个东西在业务里代表一个值，还是一个实体？它会不会被多处共享？它是不是需要频繁复制？这三个问题问完，enum、struct、class 的选择基本就水落石出了。类型设计不是语法炫耀，代码写得清楚，比代码写得“聪明”重要得多。