Rust闭包参数显式指定类型与编译器自动推断类型的差异及可变借用编译错误问题

这是个特别典型的Rust闭包类型推断和借用检查器“打架”的场景，我来给你唠明白为啥会出现这种差异～

先看你遇到的现象：
第一种情况，闭包参数靠编译器自动推断时，代码直接报E0499可变借用冲突的错误；但只要给闭包参数加上&mut i32的显式类型标注，代码就能正常编译运行，还能输出正确的结果。

先贴出两种代码对比 #

编译错误的版本（自动推断参数类型）

fn main() {
    let mut n = 0;
    let closure = |a| {
        println!("a: {:?}", a);
        f(a);
    };
    closure(&mut n);
    closure(&mut n); // 第二次调用触发错误
}

fn f(n: &mut i32) {
    *n += 1;
}

对应的编译错误：

error[E0499]: cannot borrow `n` as mutable more than once at a time
 --> src/main.rs:11:13
  |
9 |     closure(&mut n);
  |     ------ first mutable borrow occurs here
10 |
11 |     closure(&mut n);
  |     ------- ^^^^^^ second mutable borrow occurs here
  |     |        |
  |     |        first borrow later used by call
  |     first borrow later used by call

For more information about this error, try `rustc --explain E0499`.
error: could not compile `playground` (bin "playground") due to 1 previous error

编译正常的版本（显式指定参数类型）

fn main() {
    let mut n = 0;
    let closure = |a: &mut i32| {
        println!("a: {:?}", a);
        f(a);
    };
    closure(&mut n);
    closure(&mut n);
}

fn f(n: &mut i32) {
    *n += 1;
}

运行结果：

a: 0
a: 1

核心差异到底在哪？ #

咱得从Rust编译器对闭包类型推断的逻辑说起：

• 自动推断时的“死板绑定”：
  当你不给闭包参数指定类型时，编译器会根据第一次调用闭包的上下文来推断参数类型和生命周期。第一次调用closure(&mut n)时，编译器会把参数a的类型推断为&mut i32，但同时会把这个参数的生命周期绑定到第一次调用时的&mut n的具体借用上。
  这就导致闭包的类型被“焊死”成了只能接受那个特定生命周期的可变引用，第一次的借用会被闭包“持有”到后续调用，第二次再传&mut n时，就相当于尝试在第一次借用还没释放的情况下创建第二个可变借用，直接违反了Rust的“同一时间只能有一个可变借用”的核心规则，所以触发E0499错误。

• 显式指定类型时的“通用兼容”：
  当你明确写出|a: &mut i32|时，相当于直接告诉编译器：“这个闭包的参数可以是任何生命周期的&mut i32，不用局限于某一次具体的借用”。
  这时候闭包的类型会被编译成一个通用的、可以接受任意符合&mut i32类型的参数的实例。每次调用闭包时，传入的&mut n都是一个独立的借用——第一次调用结束后，借用就释放了；第二次调用时又创建一个新的可变借用，完全符合Rust的借用规则，所以能正常编译运行。

总结一下 #

简单来说就是：
自动推断类型时，编译器会根据第一次调用的上下文生成一个“专属”的闭包类型，绑定了具体的借用生命周期；而显式指定类型则让闭包变成“通用款”，能接受任何符合类型要求的参数，不会被某一次的借用生命周期限制住。这就是为啥两种写法一个报错一个正常的根本原因～

内容来源于stack exchange