企业官网建设流程全解析

Rust 错误处理开发短记：一次故障复盘留下什么

我没有线上系统可复盘，但一个练手缓存函数曾经把所有失败都写成"cache error"。测试失败时，我只能从头翻调用点，连是读取失败还是解析失败都分不出来。后来我把这个小问题当成一次复盘：先保留最小复现，再补一个能匹配错误类型的测试。

复盘不需要写成事故报告。对小项目来说，留下“触发条件、修改原因、回归测试”三项就够用。诊断信息也有边界：错误消息不要带密钥、完整路径、用户输入或内部标识；若需要关联排查，使用脱敏后的错误码或调用链标识。

use thiserror::Error; #[derive(Debug, Error, PartialEq)] enum CacheError { #[error("缓存读取超时")] Timeout, #[error("缓存内容无法解析")] InvalidData, } fn read_cache(input: &str) -> Result<u32, CacheError> { match input { "timeout" => Err(CacheError::Timeout), value => value.parse().map_err(|_| CacheError::InvalidData), } } #[test] fn timeout_keeps_its_meaning() { assert_eq!(read_cache("timeout"), Err(CacheError::Timeout)); }

这里的错误类型让调用方可以决定超时后重试、解析失败后丢弃，而不是靠匹配字符串。测试也只保证这个小契约；它不能替代真实环境中的超时、并发和日志验证。

如果要分享复盘笔记，我会只放去标识化的原因、修改和验证结果。涉及具体输入、架构或访问记录的材料应该按访问范围保存，不该作为公开样例的一部分。