anyhow：Rust应用层错误处理的事实标准，6.5K Star

Rust的错误处理机制在语言层面设计得严谨，但实际写应用时反而成了负担。标准库的 Result<T, E> 要求每个函数声明自己能返回什么错误类型，如果函数内部调用了会出IO错误的方法、会出解析错误的方法、会出网络错误的方法，这些错误类型各不相同，没法直接塞进同一个返回类型里。开发者要么自己定义一个巨型错误枚举把所有可能的情况列出来，要么到处写 map_err 做类型转换，代码很快就淹没在样板里。

dtolnay 的 anyhow 就是来解决这个问题的。它提供了一个统一错误类型 anyhow::Error，底层是基于 trait object 的包装，任何实现了 std::error::Error trait 的类型都可以往里放。你只需要把函数返回值写成 anyhow::Result<T>，然后放心用 ? 操作符传播错误，编译器不再跟你纠结类型匹配。

上下文附加是核心价值

原始的系统错误信息通常很底层，比如"No such file or directory"，单独看这条信息完全不知道是哪个业务环节出了问题。anyhow 的 .context() 和 .with_context() 方法让你在每一层调用栈附加人类可读的描述，最终错误输出形成一条清晰的因果链：最上面写清楚"正在做什么事情失败了"，下面逐层展示底层原因。排查问题时，顺着这条链就能定位到根因。

自动回溯

Rust 1.65 及以上版本中，anyhow 会自动捕获并打印 backtrace。设置 RUST_LIB_BACKTRACE=1 环境变量，出错的调用栈一目了然。对于调试复杂调用链的场景，这个功能节省了大量时间。

与 thiserror 的分工

anyhow 和 thiserror 出自同一作者 dtolnay，两者定位互补。anyhow 面向应用代码，不关心具体错误类型，只在意"出错了，把信息传上去"。thiserror 面向库作者，让你用 derive 宏精确定义自己的错误枚举，调用方可以按错误类型分别处理。实际项目中，底层库用 thiserror 定义错误，上层应用用 anyhow 统一传播，是一种常见组合。

顺手的小工具

anyhow! 宏让你随手创建一条带格式化字符串的错误信息，语法跟 format! 一致。bail! 宏进一步简化，等价于 return Err(anyhow!(...))，一行代码完成提前返回。对于流程中需要校验参数、条件不满足就报错的场景，这两个宏能省掉大量重复代码。

anyhow 还支持 no_std 环境，关闭默认的 std feature 后搭配全局 allocator 即可在嵌入式等受限场景使用，API 几乎不变。

不适合的场景

anyhow 把所有错误抹成统一类型，库作者不宜用它作为公开 API 的返回类型，因为调用方无法对错误做 downcast 分类处理。anyhow 本身支持 downcast，但那是应用内部自用，不适合向外暴露。另外 anyhow 不内置 derive 宏来生成 std::error::Error 的 impl，需要手写或用 thiserror。

小结

anyhow 目前是 Rust 应用层错误处理的事实标准。引入后错误处理代码量明显减少，可读性反而更好。对于还在手动管理错误类型转换的 Rust 应用开发者，anyhow 值得一试。

手动管理错误类型转换的 Rust 应用开发者，anyhow 值得一试。