模式匹配：match 与解构

模式匹配：match 与解构

模式匹配是 Rust 里写得最频繁的语法之一，因为枚举与 Option 的处理几乎全部经由它完成。这篇解决的问题是：match 的完整匹配规则、模式有哪几种写法、解构能拆到什么粒度、match 是否穷尽这条编译器检查如何替你挡漏分支。读完你处理枚举、Option、Result 时能写出精确而紧凑的代码，并理解「让非法状态无法表达」这句话在实践中的落点。

一、match 的三条铁律

match 语义由三条规则定义：分支自上而下匹配、模式必须穷尽所有可能、每个分支产出同类型值。函数式语言的读者会觉得理所当然，C 系语言背景的读者需要适应编译器对穷尽性的强制要求，这恰好是 match 与 switch 之间最重要的分野：

fn main() {
    let code = 404;
    let msg = match code {
        200 => "OK",
        404 => "Not Found",
        500 | 502 => "Server Error",
        _ => "其他",
    };
    println!("{}", msg);
}

_ 是通配模式，兜住一切没有列出的值；去掉它编译器会报 non-exhaustive patterns，列出该类型尚未覆盖的可能。对标 C 的 switch：switch 漏掉分支只是悄悄穿过，match 漏掉则直接编译失败。这个差别决定了 Rust 的 match 可以被当成类型安全的决策表使用，而不需要靠测试兜底，长期看它替你省下的排错时间是惊人的。

下表把 match 的核心规则总结成速查。

规则	内容	违反后果
自上而下	先匹配的分支生效	无，行为确定
穷尽性	必须覆盖所有可能	编译错误
类型一致	各分支产出同类型	类型错误
绑定变量	模式可命名捕获值	无，用于解构取值

二、模式的家族

模式远比字面值匹配丰富。常用的包括：字面量、范围（1..=100）、变量绑定、通配 _、或关系 a | b、结构体解构、元组解构、enum 变体匹配、引用解构 &v。组合使用时几乎能描述任何条件形态：

enum Shape {
    Circle(f64),
    Rect(f64, f64),
    Point { x: f64, y: f64 },
}

fn area(s: &Shape) -> f64 {
    match s {
        Shape::Circle(r) => std::f64::consts::PI * r * r,
        Shape::Rect(w, h) => w * h,
        Shape::Point { x: _, y: _ } => 0.0,
    }
}

绑定的变量还能加守卫条件（match guard）：Shape::Rect(w, h) if w == h => 限定正方形分支。守卫让匹配条件超越纯结构，代价是分支顺序更敏感——编译器仍无法判断守卫是否穷尽，所以兜底分支往往不可省。守卫最适合用在「结构相同但语义不同」的场合，比如按数值区间分流：n if n > 1000 与 n if n > 100 结构一样，只能靠守卫区分。初学者容易滥用守卫写出看不懂的分支，规则是能靠结构区分就别加守卫。

三、解构：从复合数据里取值

解构是模式的另一面：把元组、结构体、枚举按形状拆开并同时命名内部值。函数参数、let 声明、if let 都能解构：

struct User { name: String, age: u8 }

fn main() {
    let (a, b, c) = (1, "二", 3.0);           // 元组解构
    let User { name, age } = build_user();     // 结构体解构
    println!("{} {}", name, age);
    let nums = [1, 2, 3];
    let [first, ..] = nums;                    // 数组解构，.. 忽略其余
}

.. 在模式里表示「跳过其余部分」，结构体解构里尤其有用：只想取一个字段时 let Point { y, .. } = p; 比逐字段点索引简洁。解构还会 move 出字段所有权——想保留其余字段时用 ref 绑定或先解出引用。这条规则与借用规则联动，写错时的错误信息通常指向 borrow of moved value，提示你哪个字段已经被移走了。

四、if let 与 let else：轻量分支

只关心一种可能时，if let 避免写完整 match；需要「匹配不上就提前退出」时，let else 是更地道的写法。两者是 match 的语法糖，但让代码形态贴合人脑意图：

fn greet(name: Option<&str>) -> String {
    let Some(n) = name else {
        return String::from("匿名用户");
    };
    format!("你好，{}", n)
}

fn main() {
    if let Some(x) = Some(5) {
        println!("{}", x);
    }
    println!("{}", greet(Some("张三")));
}

let ... else 把「正常路径」与「异常出口」物理分开，比 if let 嵌套更清晰，是 Rust 1.65 之后的标准工具。错误处理章节会大量出现它，建议在这里就形成反射。

五、穷尽性的工程价值

编译器强制 match 覆盖全部变体，是 Rust 最省心的特性之一。给 enum 加一个变体后，所有处理该 enum 的 match 编译失败，编译器逐个位置提醒你补分支——没有比这更可靠的「变更追踪器」了。这个特性与「让非法状态无法表达」的设计哲学一脉相承：你的类型定义即穷举清单，逻辑分支藏不住，任何遗漏都变成编译错误而不是线上事故。与之配合的还有 unreachable! 宏，用于标记逻辑上不可达的分支，真走到那里会 panic。

需要暂时跳过某些变体时，用下划线兜底而非空着，但要想清楚：每次用 _ 都是放弃了穷尽检查带来的变更提醒，长项目里代价不低。能列全就列全。以编译器为协作伙伴而不是对手，是写好 Rust 的核心心法。借助 AI 工具也可以快速列出某类型的全部变体，Claude Code 使用指南里有针对编译错误展开修复的流程示例。

有个具体做法能把穷尽性用满：给每个 enum 写一个 to_str 或 kind 方法时，故意不用 _ 兜底，以后新增变体必然编译失败，等于强制自己把新情况接进来。这个习惯在团队协作时价值尤其大——review 时只要看一眼 diff 有没有新增变体，就知道还差哪些处理点。

六、模式匹配的常见坑

现象	原因	解法
覆盖警告 unreachable pattern	前面分支已吸走	删除多余分支或调整顺序
意外的通配	变量名遮蔽通配	新变量改成 `_x` 明确忽略
不能 match 浮点等值	f64 无全序	用容差比较而非 match
守卫改变穷尽判断	编译器按最保守估计	保留兜底分支

第二条值得展开：写 Some(x) => ... 时想忽略值写成 Some(_)，若写成 Some(x) 又不用 x 会得到 unused variable 警告，此时 x 既是绑定又是「看起来像通配」，用 _x 命名即可消除警告且保留「我知道它存在」的意图，团队协作中这个细节经常被新手忽略。

模式匹配：match 与解构

模式匹配：match 与解构

一、match 的三条铁律

二、模式的家族

三、解构：从复合数据里取值

四、if let 与 let else：轻量分支

五、穷尽性的工程价值

六、模式匹配的常见坑

延伸阅读