答案。

问题的历史

模式匹配是Rust中一个非常重要的语言机制，源自函数式语言。它允许以声明性、简洁且安全的方式处理复杂的值变体，特别是通过额外的条件（guard表达式），从而提供了灵活性和对逻辑的控制。

问题

没有exhaustiveness checking（穷尽性检查），模式匹配的某些强大场景可能会错误实现。此外，如果不理解分支的顺序和guard表达式，可能在逻辑或性能上犯错。

解决方案

在Rust中，编译器检查所有enum（或更简单的模式结构）的变体是否被处理，或者是否有一条_分支。这条分支可以通过guard表达式（在模式后的if）进一步限制，只有在条件满足时它才“触发”。剩余的变体则不会被捕获。分支的顺序很重要：它们是从上到下进行检查的。

代码示例：

enum Message {
    Hello,
    Data(i32),
    Quit,
}

fn handle(msg: Message) -> &'static str {
    match msg {
        Data(n) if n > 10 => "Big Data",
        Data(_) => "Some Data",
        Hello => "Greet!",
        Quit => "Bye",
    }
}

关键特点：

通过exhaustiveness checking确保安全：编译器不会让你遗漏情况（或者强制你显式使用_）。
可以使用guard扩展处理条件。
分支按顺序从上到下检查，首个匹配的模式+guard会触发。

有陷阱的问题。

如果模式匹配了但条件不满足，guard分支会触发吗？

不会，这种情况下检查会转到下一个适合的分支。模式+guard是一个原子“过滤器”；只有当两者都匹配时，分支体才会执行。

在match中，分支的顺序会影响性能吗？

会。特别是在大量相似的模式和guard时：编译器从上到下检查分支，这会影响运行时检查的速度——出现频率更高的值应优先处理。

可以只放一条_分支来跳过exhaustiveness checking吗？

从技术上讲，可以这样做，但会损失可靠性：如果类型排除（或增加）了新元素，编译器不会警告你未处理的情况。最好始终明确处理重要情况，而_仅在最后手段下使用。

常见错误和反模式

使用guard时没有意识到模式可能匹配但条件未通过：未考虑的情况。
忽视在模糊模式中分支的顺序，导致逻辑错误。
始终应穷举地处理enum，而不是全部放在_中。

生活中的例子

负面案例

带有guard表达式的enum的match代码中，guard模式在最后，但大多数值直接通过早期的_分支，导致永远无法达到所需的处理。

优点：

'_的“临时解决方案”实现快速。

缺点：

逻辑不工作，所需的值未被捕获，代码难以测试。

正面案例

首先列出最常见和重要的变体（带guard），接着穷举性涵盖其余部分——不在_中包含多余代码。