容错：错误发生后系统仍可恢复
别名: 容错性 · fault tolerance · 错误可恢复性
概念解释
容错（fault tolerance）指错误已经发生之后，系统和用户仍然能够回到一个可用、可接受的状态，而不是让一次错误直接终结任务或造成无法挽回的损失。它和防错是两个不同阶段的策略：防错发生在错误之前，目标是让错误根本不发生；容错发生在错误之后，前提是承认错误无论如何都会发生一部分，设计的重点因此从"如何拦住"转向"拦不住时怎么收场"。一个系统即使拦截率很高，只要总有漏网的错误，就需要容错来兜底。
机制
容错之所以必要，是因为没有任何防错措施能把错误率降到零——用户的意图会变化、环境会有意外、系统本身也会出现设计者没预见到的边缘状态。把全部资源投入防错，边际收益会迅速递减，而一旦真的出现没被拦住的错误，用户面对的是一个完全没有退路的系统，代价反而更高。容错的核心机制是提前保留"回退的可能性"：在错误可能发生之前，就把足够的状态信息保存下来（操作历史、中间版本、可恢复的快照），这样错误发生后，系统要做的不是重新设计一套补救方案，而是调用已经准备好的恢复路径。
怎么研究
容错能力的评估通常采用故障注入的方法：人为制造某类错误或异常输入，观察系统和用户能否在多长时间、多少步骤内恢复到可用状态，恢复过程中是否丢失了本不该丢失的数据或进度。这类研究和纯粹的错误预防研究关注点不同——预防研究问"这个错误发生的概率能不能降低"，容错研究问"这个错误一旦发生，恢复的代价有多高"，两者的因变量都不同，容错研究更关心恢复时间、恢复完整度和用户在恢复过程中需要付出的认知与操作成本。
边界
容错并不能覆盖所有类型的错误：一旦某个动作的效果已经扩散到系统边界之外（消息已经发给对方、资金已经到账、物理世界已经发生了不可逆的变化），系统内部保留的任何状态都无法把外部世界的变化收回来，容错在这种场景下能做的只是尽快让用户知情并提供补救路径，而不是真正的撤销。判断一个错误是否可容错，要看的是它的影响范围有没有越过系统能控制的边界，而不是错误本身有多严重。
怎么落地
在设计任何允许用户操作的流程时，先假设错误一定会发生，反过来问：如果这一步做错了，系统当前保留的信息够不够支持恢复？常见的手段包括在关键操作前自动生成可恢复的快照或版本、记录足够定位问题的操作日志、把不可逆的外部效果尽量往流程末尾推迟以延长内部可恢复的窗口。验证办法：人为在测试环境里对每个关键流程注入一次典型错误，计时并记录用户恢复到正常状态所需的步骤数——如果某个流程的恢复步骤数明显多于其他流程，或者恢复过程中出现数据丢失，说明这个流程的容错设计没有跟上。