? 运算符：错误的优雅传播

? 运算符：错误的优雅传播

上一章介绍了 Result 与 Option，但只要还用 match 拆解它们，错误处理就免不了层层缩进。? 运算符正是为此而生：它把「如果是错误就立即返回，是正常值就拆出来继续」压缩成一个字符。这篇解决的问题是：? 的精确语义、它如何处理类型转换、在 Option 与 Result 上用法的差别，以及它的几个隐蔽边界条件。读完你的错误处理代码会立刻短上一大截。

一、`?` 的语义：两步合一

? 跟在表达式后面，运行时做两件事：成功则解出内部值继续执行；失败则把错误作为当前函数的返回值立即返回。等价的展开式是 match：

// 两者完全等价
let n: u16 = parse(input)?;

let n: u16 = match parse(input) {
    Ok(v) => v,
    Err(e) => return Err(e),
};

从展开式能看出三个约束：当前函数必须返回 Result（或 Option），错误类型必须与函数签名匹配，且 ? 所在位置是表达式的一部分、可以接链式调用。一个不规范的说法是「? 是提前 return 的语法糖」，方向正确但漏掉了它的类型约束——正是这个约束让函数签名成为错误处理的公共契约。

关于「提前 return」还有一层直觉值得建立：? 的传播是有方向的，永远向外、逐层向上，不存在跨函数跳转。这与异常的动态栈展开截然不同：前者在编译期就确定了错误从哪条路径离场，后者要等运行时才知道。所以阅读 Rust 函数时，错误路径是静态可枚举的——扫一眼签名与问号位置，整条退路就清楚了。

二、实际使用形态

典型的多层调用场景最能体现 ? 的价值，对比展开写法就知道差距有多大：

use std::fs;
use std::num::ParseIntError;

fn read_score(path: &str) -> Result<i32, ParseIntError> {
    let text = fs::read_to_string(path)
        .map_err(|_| ParseIntError::from(std::num::IntErrorKind::Empty))?;
    let n: i32 = text.trim().parse()?;
    Ok(n * 10)
}

这里出现了 ? 两种典型位置：接在可能失败的表达式后、接在 map_err 之后做错误转换。注意一个细节：fs 的 IO 错误类型与 ParseIntError 不同，必须用 map_err 桥接；若统一换成自定义错误枚举或 anyhow，? 就能自动转换，下一节展开。

新手常犯的一个错误是把 ? 用在返回单元类型的函数里，编译器会提示 expected Result, found ()，意思是你既没有声明错误出口，却还想让 ? 帮你跑路。修复方式只有两种：给函数加上 Result 签名，或者改用 unwrap / match 就地处理，没有第三条路。

三、From 转换：自动桥接错误

? 的错误传播不是裸传递，而是先尝试 From 转换：只要当前函数的错误类型实现了 From<源错误类型>，? 会自动调用它。这就是为什么库作者喜欢定义自己的错误枚举并派生 thiserror 的 From 实现：

// 概念示意：错误枚举为每个外部错误实现 From，之后 ? 自动转换
enum AppError {
    Io(std::io::Error),
    Parse(ParseIntError),
}

fn run() -> Result<String, AppError> {
    let t = std::fs::read_to_string("a.txt")?; // IO 错误经 From 转成 AppError
    Ok(t)
}

配合 From 转换，? 把「写 map_err 桥接」的重复劳动交给 trait 推导：库的错误类型越集中，? 用起来越顺。手动为每对错误类型写 From 是标准套路，crate thiserror 用派生宏自动生成这些样板，用的是同一套机制。

错误来源	自动转换条件	不满足时
同类型	直接传播	无需处理
不同类型	目标实现 From	手写 map_err
anyhow / Box 错误	From 已为常见错误实现	手写
Option 上的 `?`	函数返回 Option	不能用于 Result 函数

四、Option 与 Result 的双面 `?`

? 同样作用于 Option：None 时提前返回 None。但两者不能混用——Result 函数里对 Option 用 ? 会编译失败，除非先 ok_or 转换。标准库为常见的「Option 里包 Result」场景给了 flatten 等工具，处理嵌套时先想清楚类型形状不匹配是哪一个。

// Option 函数里的 ?：None 即提前退场
fn first_word_len(s: &str) -> Option<usize> {
    let word = s.split_whitespace().next()?; // None 时整个函数返回 None
    Some(word.len())
}

// Result 函数里要用 Option 的值，先 ok_or 把 None 变成错误
fn load(cfg: &str) -> Result<i32, String> {
    let v: Option<i32> = parse_opt(cfg);
    let v = v.ok_or_else(|| format!("配置缺失关键字段"))?;
    Ok(v)
}

注意第二个例子中 ok_or_else 与 ok_or 的差别：前者接收闭包、仅在失败时构造错误字符串，后者立即求值。错误构造成本高时用闭包版本，这是编译器不会替你优化的运行时细节。

async 场景中 ? 的形态不变，但传播发生在 Future 的 poll 语义里，等异步章节再展开细节。main 函数也能返回 Result（标准库支持），这样 CLI 工具顶层可以直接 ?，错误以非零退出码与 stderr 信息退出。

五、该用 `?` 还是 match

一个快速判断：需要给失败值附加上下文（包一层错误或日志）时用 map_err 加 ?；需要根据成功值走不同分支时用 match 或组合子；只是「出错了就往上传」则裸 ?。三者不是竞争关系，而是分工。

意图	手法
纯传播	`?`
附加信息后传播	`map_err` 加 `?`
成功后分支处理	match 或 and_then
提供默认值	unwrap_or 系列
记录后继续	组合子加日志

一个经验性观察：? 的密度与代码可信度正相关。成熟 Rust 库的内部函数几乎每三行一个 ?，但每个函数的错误出口都清晰可循。相比之下，满屏 unwrap 的代码往往意味着错误处理还没设计完。

六、边界条件与速查

? 有三个不常被提及的边界。其一，它不是控制流关键字，而是表达式后缀，因此不能单独写在语句开头。其二，它依赖函数返回类型，闭包里使用时类型需明确（闭包的返回类型常被推断为单元类型导致报错）。其三，try block 等实验特性曾提供替代方案但未稳定，以官方文档为准。

一句话总结 ? 的价值：它把错误处理从「必须显式写分支」变成「签名里的声明式承诺」。配合 Result 的类型可见性，读代码的人看签名就知道错误从哪来到哪去。若你在迁移老代码的 match 层级，Claude Code 使用指南里有把模式匹配批量改写成 ? 的重构示例，按函数逐个替换比一次重写安全得多。写文本解析工具时这套组合尤为顺手，正则表达式精进的示例大量使用 ? 串联解析步骤，每一步失败都能精确定位到对应的解析阶段。

? 运算符：错误的优雅传播

? 运算符：错误的优雅传播

一、? 的语义：两步合一

二、实际使用形态

三、From 转换：自动桥接错误

四、Option 与 Result 的双面 ?

五、该用 ? 还是 match

六、边界条件与速查

延伸阅读

一、`?` 的语义：两步合一

四、Option 与 Result 的双面 `?`

五、该用 `?` 还是 match