Rust 错误处理短记选型先看错误边界刚学错误处理时我把anyhow用到每个函数里因为它能让我很快写下去。后来想针对一种错误给提示才发现类型信息不方便匹配。错误库不是功能越多越好关键是错误由谁处理。可复用的库代码通常要让调用方判断错误种类可以定义清楚的枚举顶层命令行程序则常常只需要把上下文串起来。thiserror和anyhow都有合适位置不该被说成非黑即白。#[derive(thiserror::Error, Debug)] enum ConfigError { #[error(配置项缺失: {0})] Missing(static str), }给用户的错误信息应足够修复问题但不包含尽量路径、账号、令牌或密码详细诊断也要脱敏后再记录。选型前我会问调用方是否需要匹配具体错误这是库代码还是应用边界失败时哪些信息绝不能输出AI 的对比表可以作为起点实际用法仍要查文档并编译最小样例。补充记录第 9 篇我会把这条建议落实为一个可复现的小检查而不是停在概念层面。先写清输入、预期行为和失败时的处理方式再在干净环境中运行最小示例结果与假设不一致时回到文档和代码定位原因。这样既能保留学习过程也不会把局部经验包装成通用结论。第 9 篇的收尾检查是删掉无关输入保留一个能失败的反例并写下我准备如何确认修复是否真的生效。若没有可执行的检查就把结论标为待验证而不急着把它变成规则。第 9 篇的延伸练习把文中的判断拆成一张小表。第一列写触发条件例如输入超过限制、依赖返回异常或调用者取消第二列写程序可观察到的信号例如错误类型、队列状态或测试断言第三列写允许的处理动作以及谁有权执行它。随后只实现其中一条最小路径并故意制造失败输入检查结果。若失败路径没有明确输出就不要继续增加功能。这样做虽然比让工具直接补全整段代码慢但能迫使我先理解所有权、资源释放和调用方预期。完成后再删去不必要的分支补上一个回归测试并把运行命令与限制条件记在提交说明里。读者若要采用相同思路应替换为自己的编译器版本、依赖版本和业务目标示例不能替代项目验证。第 9 篇还应补一个边界案例当输入为空、依赖不可用或用户中途取消时程序是否仍能给出可理解的结果。把这些案例写成小测试后再检查日志是否泄露路径、账号或原始内容。只有正常路径和失败路径都能说明白才把这段做法放进自己的工作流。第 9 篇的发布前检查确认标题没有承诺超出正文的范围示例代码能独立阅读参数没有被写成通用答案再让一位不了解上下文的人按步骤复述风险点。如果对方无法判断何时该停止或回退就继续删减结论、补充限制而不是增加口号。第 9 篇的最后一步是把检查结果保存在能被后来人找到的位置并在下次修改时重新运行。