解读

在国内 Rust 社招/校招面试里，这道题常被用来区分“写过模式匹配”与“真正理解模式匹配”。
很多候选人能背出“先匹配模式，再求值 guard”，却说不清求值发生的时机、借用检查的影响、短路逻辑与副作用顺序。
面试官往往追问：

1. 如果 guard 里调用函数，会不会因为模式不匹配而跳过？
2. 若 guard 里 mut 借用同一变量，编译器为何报错？
3. 多个 | 分支带 guard 时，短路顺序如何保证？
   答不到这三层，基本会被判定“只写过 hello-world 级 match”。

知识点

1. 匹配阶段：Rust 按分支自上而下尝试模式；模式匹配成功后才进入该分支的 guard。
2. guard 求值时机：模式匹配成功 → 绑定变量 → 求值 guard 表达式；guard 为 false 则退回并继续下一分支，不会回溯重试已失败模式。
3. 借用规则：guard 表达式与模式绑定共享同一作用域，任何在 guard 里产生的可变借用，必须在该分支内结束，否则编译器直接拒绝（防止“绑定不可变却通过 guard 偷偷 mut”）。
4. 短路顺序：guard 内表达式按从左到右、短路求值（&&、||、if let 同理）；副作用在求值瞬间发生，与是否进入分支无关。
5. 性能语义：guard 失败不会触发任何该分支内的临时变量 drop，零成本抽象在此依然成立。

答案

Rust 对带 if guard 的 match 分支采用**“先模式，后 guard”**的严格顺序：

1. 编译器按书写顺序自上而下尝试模式；
2. 一旦模式匹配成功，立即绑定所有变量；
3. 绑定完成后再求值 guard 表达式；
4. 若 guard 为 true，进入该分支执行 => 右侧代码；
5. 若 guard 为 false，放弃该分支，继续下一分支，不会重新求值已跳过的模式。
   guard 表达式内的求值遵循正常表达式规则，从左到右、短路求值，且与绑定变量处于同一作用域，因此guard 里对绑定变量的借用必须满足 Rust 的借用检查，否则编译期直接报错。整个流程保证无副作用的回溯，也符合 Rust 零成本抽象的设计目标。

拓展思考

1. 嵌套 guard 与 or 模式：
   写 match Some((1, 2)) { Some((a, b)) if a == 1 && b == 2 => {}, _ => {} } 时，先匹配最外层 Some，再匹配元组，最后求值 a == 1 && b == 2；若把 && 换成 ||，左侧 true 后右侧会被短路跳过，可用于避免不必要的函数调用。

2. guard 与临时可变借用：
   代码 match &mut v { x if x.len() > 0 => x.push(1), _ => {} } 能通过编译，因为 guard 里的不可变借用立即结束；
   但若写成 x if { x.push(1); false } => {} 则编译失败——guard 里 mut 借用与绑定不可变借用冲突，体现了 Rust 把 guard 与模式绑定视为同一作用域的严格性。

3. 实战性能陷阱：
   在热点循环中把昂贵计算放进 guard，会导致每次模式匹配成功都重复执行；应提前计算或把复杂判断拆成分支，避免隐式重复求值带来的开销。