答案

在Rust中，枚举（enums）不仅可以存储值（variants），还可以存储与之关联的数据（payload）。这使得它们在创建代数数据类型时尤其方便，例如用于表示状态或带参数的消息。例如：

enum Message {
    Quit,
    Move { x: i32, y: i32 },
    Write(String),
    ChangeColor(i32, i32, i32),
}

对于这样的枚举，通常使用match运算符来解包每个变体的嵌套值：

let msg = Message::Move { x: 10, y: 20 };

match msg {
    Message::Quit => println!("Quit message"),
    Message::Move { x, y } => println!("Move to ({}, {})", x, y),
    Message::Write(text) => println!("Text: {}", text),
    Message::ChangeColor(r, g, b) => println!("Change color to ({}, {}, {})", r, g, b),
}

这种方法允许安全且明确地处理所有可能的情况，从而最小化程序逻辑中的错误。

陷阱问题

为什么Rust中的枚举没有null，以及尝试匹配不存在的变体会返回什么？

常见的错误答案是：“如果在match中不处理所有枚举的变体，编译器会忽略错误。”

实际上，如果没有考虑所有可能的变体，编译器会报错，或者要求添加catch-all（_）。例如：

enum Status { Ok, Err(String) }
let st = Status::Ok;
match st {
    Status::Ok => println!("Ok"),
    // 如果忘记Status::Err，编译器会抱怨
}

由于不了解主题的细微之处而导致的真实错误示例

---

故事 在一个项目中，扩展枚举时没有在所有使用它的地方添加对新变体的match处理。这导致在发布时出现panic！，因为match不是穷尽性的（exhaustive），同时测试并未覆盖所有案例。

---

事情 在另一个案例中，试图使用常规的==比较枚举，但对于关联数据的复杂变体没有实现PartialEq，这导致了意外的编译错误。

---

故事 团队使用catch-all（_）来处理变体，后来在添加新变体时，这导致逻辑默默忽略了新情况，从而导致难以查找的缺陷。