在 Rust 中，枚举（enum）和结构体（struct）是两种最常用的自定义数据类型，但它们解决的问题不同。很多新手会纠结该用哪个，其实只要抓住核心区别：枚举表达“或”的关系，结构体表达“且”的关系。下面结合具体场景说明各自的适用边界和取舍。

何时选择枚举而不是结构体

当需要表示一个值可能属于多个互斥类型之一时，枚举比结构体更合适。例如网络消息类型、状态机的状态或错误类型。枚举的每个变体可以携带不同类型的数据，编译器会确保所有变体都被处理（通过 match 穷举），避免遗漏分支。而结构体只能固定一组字段，无法表达“或”的关系。如果变体数量可能动态增加，应优先考虑枚举而非结构体组合，否则后续扩展需要修改结构体定义。

一个常见的误用是用结构体加标志字段来模拟枚举，比如 struct HttpMessage { kind: u8, body: Vec<u8> }，然后通过匹配 kind 字段处理不同消息。这样不仅需要写很多 if-else，而且新增消息类型时必须修改所有匹配 kind 的逻辑，容易遗漏。改用枚举 enum HttpMessage { Get(Vec<u8>), Post(Vec<u8>), ... }，编译器会强制你处理所有变体，扩展时也会在未处理的分支上给出警告。

结构体适合哪些数据聚合场景

结构体用于将一组相关联的数据字段组合成一个单一类型，每个字段有明确的名称和类型。当你需要表示一个对象的属性集合（如用户信息包含姓名、年龄、邮箱），且所有属性同时存在时，结构体是最直接的选择。枚举的每个变体虽然也能携带字段，但多个变体之间字段可能不同，不利于通过统一接口访问固定属性。若需要频繁访问、修改或序列化一组固定字段，结构体更清晰。

例如一个网络配置的结构体：struct Config { host: String, port: u16, timeout: Duration }，所有字段都是必填且固定，使用结构体可以直接 config.host 访问。如果用枚举，每个变体里字段不同，且需要额外 match 才能拿到 host，徒增复杂性。结构体在序列化（serde）时也更为直观：字段名直接映射为 JSON 键，而枚举的变体名称需要额外适配。

状态机设计中的枚举优势

在实现状态机或工作流时，将每个状态定义为枚举的变体，并将状态转换逻辑封装在方法中，能强制编译器检查所有状态转换的合法性。例如网络连接的状态（未连接、连接中、已连接、断开）若用结构体字段（如 is_connected: bool）表示，容易暴露非法状态组合，而枚举穷举所有有效状态，避免无效状态出现。转换时通过 match 匹配当前状态并返回下一个状态，逻辑集中且易于验证。

举例来说，一个 TCP 连接的状态机：enum TcpState { Closed, Listen, SynSent, SynReceived, Established, FinWait1, ... }，每个状态下的转换方法 fn receive_syn(self) -> TcpState 会 match self，只允许合法转换。如果误传了非法状态，编译器会在 match 分支中报错（因为未覆盖的变体），而结构体的 bool 组合 struct TcpState { syn_sent: bool, ack_received: bool, ... } 很难防止 syn_sent=true & ack_received=true 这种无意义组合。

错误处理中枚举的典型用法

Rust 中定义自定义错误类型时，通常用枚举列出所有可能的错误变体（如 IoError、ParseError、TimeOutError），每个变体可携带不同错误细节。这样调用方可以通过 match 精确处理每种错误，或使用 ? 运算符将错误向上传播。若用结构体包裹一个错误码字段，则丧失类型安全，且必须手动 match 错误码，容易遗漏。标准库中 std::error::Error trait 通常基于枚举实现，可见其优势。

一个实际的例子是解析 JSON 时可能遇到 IO 错误、语法错误或类型错误：enum JsonError { Io(io::Error), Parse(String), TypeError { expected: &'static str, found: &'static str } }。调用方可以单独处理 JsonError::Parse(msg) 打印友好信息，而用 ? 在函数间传递时，底层错误细节仍然保留。如果用结构体 struct Error { code: i32, message: String }，则每个错误码的含义需要文档解释，且扩展新错误时必须保证 code 不冲突，维护成本更高。

性能与内存布局的取舍点

枚举的大小取决于其最大变体，所有变体共享同一块存储空间，因此适合变体大小差异不大且数量有限的场景。如果变体中某个变体携带非常大的数据，枚举整体尺寸会增大，可能影响栈空间或内存对齐。结构体的大小则是所有字段大小之和，适合字段体积固定且需要频繁访问的场景。若变体间大小悬殊且数量较多，可考虑将大体积数据用 Box 包装以减少枚举栈尺寸，但会增加一次堆分配。

判断方法：用 std::mem::size_of::<T>() 查看枚举和结构体的大小。例如 enum E { A(u32), B(u64, u64) } 的大小可能是 16 字节（因为 B 变体占 16 字节，A 也占 16 字节，两者取最大并对齐）。如果 B 变体改为 B(Box<[u8; 1024]>)，枚举大小可能降为 8 或 16 字节（指针大小），但访问大数据时需要解引用。结构体 struct S { a: u32, b: [u8; 1024] } 大小约 1028 字节，栈上拷贝开销大。因此在需要栈上高效复制且字段固定时用结构体，在需要表达多态且节省栈空间时用枚举 + Box。

最后一个小提示：如果你发现一个结构体中有很多 Option 字段，且不同组合代表不同“模式”，这往往是应该用枚举重构的信号。可以先列出现有的有效组合，把它们定义为枚举变体，再逐步替换。这样后续新增模式时，只需增加一个变体，编译时会提示你所有涉及 match 的地方需要更新，比修改结构体字段并检查所有 if-else 更安全。