错误处理与 Result/Option：高频问题、回答框架、公司侧重点
Rust 服务端面试中，错误处理是必考核心模块。面试官通过 Result/Option 考察你的代码健壮性意识、错误传播策略及生产级实践认知。以下回答框架可应对 80% 相关题目。
Result vs Option 核心对比
| 维度 | Result<T, E> | Option<T> |
|---|---|---|
| 语义 | 可能成功（Ok）或失败（Err） | 可能有值（Some）或空（None） |
| 错误信息 | 携带错误类型 E | 无额外错误信息 |
| 典型场景 | 文件读取、网络请求、数据库操作 | 集合查找、空值检查、可选配置 |
| 转换关系 | Ok → Some, Err → None（通过 .ok()） | Some → Ok(()), None → Err(…) |
| 面试重点 | 错误传播、自定义错误、错误链 | Option 组合子、unwrap_or 等 |
🎯 面试问题 1：谈谈你对 Result 和 Option 的理解，以及使用场景
概念考察点： 是否区分“可恢复错误”和“不可恢复错误”；是否理解二者在设计哲学上的差异。
回答框架： 1. 给出定义与枚举结构 → 2. 对比语义差异（失败 vs 无值）→ 3. 举例说明常见场景 → 4. 强调不可滥用 Option 替代 Result。
简短示例回答：
Result<T, E> 表示可能成功或失败，E 提供错误信息；Option<T> 只表示值存在与否。项目中用 Result 处理 IO、网络等可恢复错误，用 Option 处理集合查找、配置项缺失。不推荐用 None 携带错误语义，会丢失原因。可能追问： “Error 类型如何设计？” “Option 的 ok_or 方法底层如何转换？”
避坑提醒： ❌ 不要回答“Option 就是只有两种状态的 Result”，二者语义不同；避免混淆 unwrap 和 expect 的适用场景。
🎯 面试问题 2：你在项目中如何优雅处理多个可能失败的操作链？
概念考察点： 是否掌握 ? 操作符、组合子、错误转换、自定义错误类型。
回答框架： 1. 明确链式调用特点 → 2. 使用 ? 传播错误 → 3. 引入 thiserror / anyhow 简化错误转换 → 4. 必要时用 map_err 添加上下文 → 5. 统一返回自定义 Error 类型。
简短示例回答：
定义自定义错误枚举（集成 thiserror），每步函数返回 Result<T, MyError>，用 ? 自动转换。例如：读取配置文件 → 解析 JSON → 校验字段，全链路统一错误类型，无需每步手动 match。可能追问： “如何处理不同库抛出的多种错误？” “? 操作符的底层实现原理？”
避坑提醒： ❌ 避免在链路中混用 unwrap，一旦失败直接 panic；推荐先设计错误类型再实现业务逻辑。
🎯 面试问题 3：你认为在企业级项目中应该用什么策略处理错误？
概念考察点： 生产环境实践认知：日志、错误穿透、客户端友好错误、监控报警。
回答框架： 1. 区分边界错误（外部输入）和内部错误 → 2. 使用 Result 包装所有可恢复错误 → 3. 通过 thiserror 定义结构化错误 → 4. 在顶层（如 web handler）统一处理，记录日志并返回友好消息 → 5. 不可恢复错误使用 panic! / expect 仅限测试或初始化。
简短示例回答：
项目中使用 thiserror 定义错误类型，ErrorHandler 中间件捕获所有 Result::Err，记录结构化日志（含错误链），返回统一 JSON 格式。内部链路全部用 ? 传播，只有手动触发 panic 的场景是配置缺失导致进程退出。可能追问： “如何避免错误信息泄漏敏感数据？” “如何处理超时/重试时的错误？”
避坑提醒： ❌ 不要在生产代码直接返回内部错误细节，防止安全风险；不要滥用 panic!，应优先使用 Result 让调用方处理。