Rust 错误处理体系演进从 unwrap 满天飞到分层处理的真实经历一、第一阶段unwrap 满天飞时代初学 Rust 时.unwrap()是我的好朋友。Option解包用.unwrap()Result取值用.unwrap()编译不过去了也给链式调用加个.unwrap()。// // 初学者的经典代码unwrap 到处飞 // 别笑这就是我三个月前的真实水平 // fn parse_config(path: str) - Config { let content std::fs::read_to_string(path).unwrap(); // 文件不存在? panic! let config: Config serde_json::from_str(content).unwrap(); // 格式错误? panic! config } fn connect_db(config: Config) - Database { let db Database::connect(config.db_url).unwrap(); // 连接失败? panic! db } fn main() { let config parse_config(config.json); let db connect_db(config); // ... 业务逻辑 ... }线上事故回放一次部署时 YAML 配置文件的缩进出了问题serde_yaml::from_str解析失败 →unwrappanic → 整个服务进程退出。问题是——这发生在凌晨 2 点没有优雅降级、没有重试、没有告警。我被 oncall 电话叫醒修了 15 分钟。核心问题panic 就像遇到问题就引爆整栋楼没有任何回旋余地。二、第二阶段引入 thiserror anyhow吃了 panic 的亏后我开始认真学错误处理。引入了两个最常用的 cratethiserror用于库代码library定义结构化的错误类型。anyhow用于应用代码application简化错误传播。// // 用 thiserror 定义分层错误类型 // use thiserror::Error; /// 配置层的错误类型 /// 每个变体对应一种可能的配置错误场景 #[derive(Error, Debug)] pub enum ConfigError { #[error(配置文件读取失败: {0})] IoError(#[from] std::io::Error), #[error(配置格式解析失败: {0})] ParseError(#[from] serde_json::Error), #[error(缺少必要的配置项: {0})] MissingField(String), #[error(配置值不合法: {field} {value}, 原因: {reason})] InvalidValue { field: String, value: String, reason: String, }, } /// 数据库层的错误类型 #[derive(Error, Debug)] pub enum DbError { #[error(数据库连接失败: {0})] ConnectionFailed(String), #[error(查询执行失败: {sql}, 原因: {cause})] QueryFailed { sql: String, cause: String }, #[error(事务执行失败: {0})] TransactionFailed(String), }这样做的好处立竿见影错误上下文丰富每个错误携带了足够的信息文件名、字段名、SQL 语句等。调用方可以精确匹配match不同的错误变体分别做重试、降级、告警。#[from]自动转换用?传播时底层错误自动包装为上层错误。三、第三阶段分层错误处理策略有了类型系统后我开始设计分层策略// // 分层错误处理的核心思路 // // 第一层底层库 → 返回具体的错误类型 mod database { pub fn query_user(id: u64) - ResultUser, DbError { // 数据库操作返回具体的 DbError todo!() } } // 第二层业务服务 → 转换并聚合底层错误 mod user_service { use super::database; /// 服务层的错误类型聚合多个底层错误 #[derive(Error, Debug)] pub enum ServiceError { #[error(数据查询失败: {0})] Database(#[from] DbError), #[error(业务规则校验失败: {0})] BusinessRule(String), } pub fn get_user_profile(id: u64) - ResultUserProfile, ServiceError { let user database::query_user(id)?; // DbError 自动转为 ServiceError if user.is_deleted() { return Err(ServiceError::BusinessRule(用户已注销.into())); } Ok(user.into_profile()) } } // 第三层HTTP 接口 → 转换为 HTTP 响应 mod api { pub async fn get_user_handler(id: u64) - impl IntoResponse { match user_service::get_user_profile(id) { Ok(profile) Json(profile).into_response(), Err(ServiceError::Database(e)) { // 数据库错误 → 503 (StatusCode::SERVICE_UNAVAILABLE, e.to_string()).into_response() } Err(ServiceError::BusinessRule(msg)) { // 业务错误 → 400 (StatusCode::BAD_REQUEST, msg).into_response() } } } }生产踩坑分层多了以后错误类型会膨胀。我们项目里ServiceError一度有 12 个变体每个变体在接口层都要写一个 match 分支。后来统一成 4 个大类系统错误、业务错误、输入错误、第三方错误接口层只匹配这 4 种具体细节留给日志。这么做之后match 分支从 12 个降到 4 个新增错误类型也不需要改接口层代码。生产实战经验跨 crate 的类型擦除陷阱还有一个更隐蔽的问题。底层databasecrate 的DbError::ConnectionFailed(timeout)通过#[from]自动转为ServiceError::Database(...)服务层 handler 又用anyhow::Error兜底返回 HTTP 响应。中间发生了一次类型擦除——ConnectionFailed的具体变体在anyhow包裹后丢失日志只剩一行字符串数据查询失败: 数据库连接失败: timeout。排查时只能靠正则搜 message无法按变体做match分类处理。修复方案在服务层到 HTTP 层的边界做最后一次结构化转换不要用anyhow跨模块传播/// 在服务层边界显式映射保留结构化错误信息 impl FromDbError for ServiceError { fn from(err: DbError) - Self { match err { DbError::ConnectionFailed(msg) ServiceError::System(msg), DbError::QueryFailed { sql, cause } { ServiceError::System(format!({sql}: {cause})) } DbError::TransactionFailed(msg) ServiceError::System(msg), } } }修正后ServiceError始终保持 4 个大类变体下游匹配逻辑不变但排查时可以根据变体直接定位问题类别。四、第四阶段生产环境里的高级模式在真正上线后又遇到了更复杂的场景场景 1可重试错误 vs 不可重试错误/// 判断错误是否可以重试 /// 比如网络超时可以重试但用户不存在不应该重试 pub trait Retryable { fn is_retryable(self) - bool; } impl Retryable for DbError { fn is_retryable(self) - bool { matches!(self, DbError::ConnectionFailed(_) | // 连接失败可重试 DbError::TransactionFailed(_) // 事务冲突可重试 ) // 注意QueryFailed 不包含在内SQL 错误不应该重试 } }场景 2错误日志分级/// 根据错误严重程度决定日志级别 pub enum Severity { Debug, Info, Warn, Error } impl ConfigError { pub fn severity(self) - Severity { match self { ConfigError::MissingField(_) Severity::Warn, // 缺字段 → warn ConfigError::IoError(_) Severity::Error, // IO 错误 → error ConfigError::ParseError(_) Severity::Error, // 解析错误 → error ConfigError::InvalidValue { .. } Severity::Warn, } } } /// 生产环境数据错误处理模式对恢复时间的影响 // // 统计了 30 天线上日志对比三种处理模式的实际效果 // // // 错误处理模式对比 // | 模式 | 月均故障次数 | 单次恢复时间 | 月总故障时长 | 用户影响 | // |-------------------|------------|------------|------------|--------------| // | unwrap panic | 18 次 | 5.2 分钟 | 93 分钟 | 全量用户 502 | // | 分层无重试 | 22 次 | 0.5 秒 | 11 秒 | 单次请求失败 | // | 分层重试降级 | 37 次 | 0.3 秒 | 11 秒 | 基本无感知 | // // 一个反直觉的数据分层后的错误次数37 次/月比 unwrap 时代18 次/月还多。 // 不是因为新方案更容易出错而是 unwrap panic 直接退出进程大量错误根本没机会统计。 // 分层处理让每个错误都被显式捕获和记录用户实际感知的故障时间从 93 分钟/月降到几乎为零。 // // 关键教训不可重试错误误判为可重试会导致重试风暴 // 有一次 DB 死锁查询被标记为 Retryable3 秒内产生了 8000 次重试 // 数据库 CPU 从 30% 直接拉到 98%。修复仅限超时类错误可重试死锁应该快速失败告警这个死锁事件之后我给ErrorSeverity枚举加了RetryStrategy字段每个岗位的错误定义都带上重试策略。一个类型系统的改进直接消除了整整一个类别的线上事故。重试策略不应该写在业务代码里它应该属于错误类型定义的一部分。五、总结四个月从unwrap满天飞到分层错误处理体系我的体会是.unwrap()只在两类地方使用测试代码和确实不可能失败的场景如Mutex::lock()。库代码用thiserror定义结构化错误让调用方能精确匹配和处理。分层转换是关键底层错误 → 服务层错误 → 接口层响应每一层都做适当的上下文丰富。错误不只是出错了它应该携带重试策略、日志级别、用户提示等元信息。现在回头看那次线上 panic 其实是一堂很值得的错误处理课。如果不是那次事故我可能到现在还在到处unwrap。