深入理解Rust中的Result类型

Result类型：处理错误的正确姿势

写代码时，谁都不想遇到错误。但现实是，文件打不开、网络连不上、数据解析失败，这些情况太常见了。Rust没有像其他语言那样用异常机制来处理这类问题，而是用了一个叫Result的类型，把错误处理变成编码的一部分。

Result是个枚举，定义很简单：

enum Result<T, E> {
    Ok(T),
    Err(E),
}

它有两个分支：Ok代表成功，里面装着你要的数据；Err代表出错，里面是具体的错误信息。这种设计强迫你在使用结果前先考虑失败的可能性，而不是等程序崩溃才反应过来。

从一个读文件的例子说起

假设你要读取配置文件config.txt，在Rust里会这么写：

use std::fs::File;
use std::io::Read;

fn read_config() -> Result<String, std::io::Error> {
    let mut file = File::open("config.txt")?;
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;
    Ok(contents)
}

这里用了?操作符，它像是一个“甩锅神器”。如果前面的操作返回Err，函数就直接返回这个错误；只有Ok才会继续往下走。这样代码看起来干净，也不会漏掉错误处理。

匹配错误，做出应对

有时候你不想直接向上抛，而是想自己处理错误。比如用户没配文件，那就用默认值顶上：

let config = match read_config() {
    Ok(content) => content,
    Err(_) => String::from("default=value"),
};

这种match写法虽然啰嗦点，但逻辑特别清楚。你一眼就能看出程序在不同情况下会怎么反应，不像某些语言的try-catch，嵌套深了根本看不懂。

别随便用unwrap

新手常犯的一个错误是到处用unwrap()。它确实方便，Ok就拿值，Err就panic。但线上服务要是因为一个配置文件打不开就崩了，运维肯定找上门。

就像做饭时发现没盐，你可以选择停下来不做了（panic），也可以改做一道不需要盐的菜（错误恢复）。Rust鼓励你选后者。

组合子让链式调用更流畅

除了match和?，Result还支持map、and_then这类方法。比如你想读文件后再转成大写：

let result = read_config()
    .map(|s| s.to_uppercase());

如果读取失败，map不会执行，错误会自动传递。这种方式让数据转换流程变得像流水线，一环接一环，还自带错误隔离。

Rust的Result不是为了增加复杂度，而是让你写出更可靠的程序。它不让你假装错误不存在，而是逼你面对它、处理它。时间久了你会发现，这种“麻烦”其实省去了更多半夜被报警叫醒的烦恼。