Tokio select!宏分支前置条件判断时，非async块包裹的调用出现提前求值触发panic的原因

这个问题的核心藏在Rust表达式的求值顺序和Tokio select!宏的分支处理逻辑里，我给你一步步拆解清楚：

1. 为什么不加async{}会直接触发panic？ #

先看你写的这段有问题的代码：

async fn foo(x: u32) {}
let maybe: Option<u32> = None;
select! {
    _ = foo(maybe.unwrap()), if maybe.is_some() => (),
    _ = async { some_other_branch().await } => (),
}

这里的关键是：foo(maybe.unwrap())中，maybe.unwrap()是传递给foo的实参。在Rust里，调用任何函数（包括async函数）之前，必须先计算所有参数的值——这个求值过程是立即发生的，完全不受后面if maybe.is_some()前置条件的控制。

也就是说，当select!宏还没来得及检查你的前置条件时，maybe.unwrap()就已经执行了，而maybe是None，自然直接触发panic。

简单说：参数求值的时机早于select!的条件判断，直接踩中了unwrap的陷阱。

2. 为什么加了async{}就安全了？ #

再看这段正确的代码：

async fn foo(x: u32) {}
let maybe: Option<u32> = None;
select! {
    _ = async { foo(maybe.unwrap()).await }, if maybe.is_some() => (),
    _ = async { some_other_branch().await } => (),
}

用async {}包裹后，这个代码块会生成一个新的Future对象，但里面的所有代码（包括maybe.unwrap()和foo的调用）并不会立即执行——只有当这个Future被Tokio调度器poll（也就是这个分支被选中执行的时候），里面的代码才会运行。

而select!宏的逻辑是：先检查每个分支的前置条件，只有条件为true的分支，才会把对应的Future加入到等待执行的集合中。当maybe是None时，if maybe.is_some()条件不满足，这个分支直接被跳过，对应的Future根本不会被poll，里面的unwrap()自然不会被执行，也就不会panic。

额外补充个小细节 #

你可以这么理解select!的分支处理顺序：

1. 先检查每个分支的前置条件；
2. 只把条件为true的分支对应的Future加入等待队列；
3. 等待这些Future中的一个完成，执行对应的逻辑。

但如果把需要保护的代码（比如unwrap）放在“创建Future”的表达式里（也就是等号右边的直接调用），那创建Future时的参数求值是早于条件判断的，所以根本得不到前置条件的保护。而async块相当于把危险代码延迟到了Future被执行的阶段，这时候前置条件已经把不符合的分支过滤掉了，自然就安全了。

备注：内容来源于stack exchange，提问作者jsstuball