为何Rust中.ok_or()可用但.ok_or_else()出现类型匹配错误？

问题重现 #

以下代码使用ok_or_else会触发类型不匹配的编译错误：

use std::error::Error;
use std::fmt;

#[derive(Debug)]
struct APIError {
    message: String,
}

impl fmt::Display for APIError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "{}", self.message)
    }
}

impl Error for APIError {}

fn example_function() -> Result<String, Box<dyn Error>> {
    let option: Option<String> = None; 

    option.ok_or_else(|| {
        Box::new(APIError {
            message: "Custom error message".to_string(),
        })
    })
}

fn main() {
    match example_function() {
        Ok(value) => println!("Success: {}", value),
        Err(e) => println!("Error: {}", e),
    }
}

错误信息：

error[E0308]: mismatched types
  --> src/main.rs:22:5
   |
19 |   fn example_function() -> Result<String, Box<dyn Error>> {
   |                            ------------------------------ expected `Result<String, Box<(dyn std::error::Error + 'static)>>` because of return type
...
22 | /     option.ok_or_else(|| {
23 | |         Box::new(APIError {
24 | |             message: "Custom error message".to_string(),
25 | |         })
26 | |     })
   | |______^ expected `Result<String, Box<dyn Error>>`, found `Result<String, Box<APIError>>`
   |
   = note: expected enum `Result<_, Box<(dyn std::error::Error + 'static)>>`
              found enum `Result<_, Box<APIError>>`

但将ok_or_else替换为ok_or后，代码可正常编译：

option.ok_or(
    Box::new(APIError {
        message: "Custom error message".to_string(),
    })
)

类型推断规则差异分析 #

1. ok_or的类型推导逻辑 #

ok_or的签名为：

fn ok_or<T, E>(self, err: E) -> Result<T, E>

当函数返回值要求Result<String, Box<dyn Error>>时，编译器会反向推导参数err的类型：它知道需要E为Box<dyn Error>，而Box<APIError>可以被强制转换为Box<dyn Error>（因为APIError实现了Error trait，且Box<T>对 trait 对象具有协变性）。这种从返回值到参数的反向类型推导是直接可行的。

2. ok_or_else的类型推导逻辑 #

ok_or_else的签名为：

fn ok_or_else<T, F, E>(self, f: F) -> Result<T, E>
where
    F: FnOnce() -> E,

这里的核心差异在于闭包的类型推断是局部优先的：编译器会先根据闭包内部的代码推导其返回类型，再匹配外部的返回值要求，而非反过来。

闭包|| Box::new(APIError { ... })的返回类型会被直接推断为Box<APIError>——因为闭包内部明确返回了这个具体类型，编译器不会提前参考外部函数的返回值来调整闭包的类型。此时ok_or_else返回的Result错误类型被固定为Box<APIError>，与外部要求的Box<dyn Error>不匹配，因此触发编译错误。

Rust设计这种局部优先的闭包推断规则，是为了避免上下文依赖导致的歧义，保证闭包行为的可预测性——如果允许外部上下文随意修改闭包的返回类型，复杂场景下会出现推断混乱。

印证：让ok_or_else正常工作的方式 #

如果显式指定闭包的返回类型，编译器就能匹配外部的返回值要求：

option.ok_or_else(|| -> Box<dyn Error> {
    Box::new(APIError {
        message: "Custom error message".to_string(),
    })
})

或者通过显式类型转换强制改变闭包的返回类型：

option.ok_or_else(|| {
    Box::new(APIError {
        message: "Custom error message".to_string(),
    }) as Box<dyn Error>
})

内容的提问来源于stack exchange，提问作者zsf222