Rust中是否有更函数式的方式处理Result的两种分支调用？

你的这种“成功执行一个逻辑、失败执行另一个”的场景在Rust里非常常见，先直接给结论：

• 你最初的match写法完全符合Rust风格，是通用且清晰的标准方案；
• 标准库中确实有更简洁的链式调用方法，不需要自己实现on_ok/on_err。

1. 用inspect和inspect_err实现链式副作用 #

Rust标准库的Result提供了inspect和inspect_err方法，专门用于在不修改Result本身的前提下，对Ok/Err分支执行副作用（比如打日志），语义上完全匹配你的需求：

client.favourite(&status.id)
    .inspect(|_| info!("Favourited {}", &status.id))
    .inspect_err(|err| error!("Could not favourite {}: {:#?}", &status.id, err));

这两个方法会原样返回原Result，所以你后续还可以继续链式调用其他Result方法（比如unwrap、expect或者进一步处理）。

2. 用map和map_err（语义稍弱但可行） #

如果你的Rust版本比较旧（低于1.31），可以用map和map_err替代：

client.favourite(&status.id)
    .map(|_| {
        info!("Favourited {}", &status.id);
        ()
    })
    .map_err(|err| {
        error!("Could not favourite {}: {:#?}", &status.id, err);
        err
    });

不过map/map_err的核心语义是转换值，不是执行副作用，所以用它们来打日志属于“借用”功能，不如inspect系列语义准确。

关于unwrap_or_*系列方法 #

unwrap_or、unwrap_or_else这类方法的作用是提取Ok值，或者在Err时返回一个替代值/生成替代值，它们的核心是获取值，而不是执行副作用，所以不适合你的场景。

回到match写法 #

match本身就是Rust处理Result和Option的“瑞士军刀”，没有任何不符合风格的问题。当你的分支逻辑复杂（比如需要多个步骤、条件判断），或者需要更明确的代码可读性时，match是最佳选择；只有当逻辑是简单的副作用执行时，链式调用的方法会更简洁。

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