Fail-fast（快速失败）是一种设计原则：当系统检测到一个不该发生的状态时，应当立即、显眼地失败，而不是带着错误继续运行下去。它的核心主张是——把问题暴露在离源头最近的地方，让错误尽早被发现，而不是拖到后面变成难以排查的怪现象，或者悄无声息地产出错误结果。

Jim Shore 在 Martin Fowler 主持的 IEEE Software「Design」专栏上写过一篇就叫《Fail Fast》的短文（2004 年 9/10 月号），把这个原则讲得很直接：带着错误「慢慢失败」（failing slowly）的程序会在后面以奇怪的方式出问题，而 fail-fast 的系统则在问题发生的当下就立即、显眼地失败（fail immediately and visibly）——看似更脆弱，实则更健壮，因为缺陷更容易被发现和修复。原文可读 Fowler 站点上的 Fail Fast (PDF)，作者本人也在 jamesshore.com 上做了简介。

它要解决的问题

很多 bug 难查，不是因为错误本身复杂，而是因为错误发生的位置和错误暴露的位置离得很远。

设想一个函数收到了一个非法参数（比如本不该为 null 的值），它没有检查，而是默默接受、继续往下传。这个坏值可能流过好几层调用、被写进缓存、存进数据库，直到很久以后在某个完全不相干的地方抛出一个莫名其妙的异常。这时你拿到的堆栈和真正的出错点已经隔了十万八千里。

fail-fast 的思路是反过来：在边界上就把关，一发现状态不对就立刻停下来报错。错误在源头炸掉，定位成本最低。

几个常见的例子

fail-fast 不是某一种具体技术，而是一类做法，散落在很多地方：

  • 参数 / 前置条件校验：方法一进来就检查参数，非法立刻抛异常，而不是带病运行。
  • 断言（assertions）：用断言把「不该发生」的假设显式写出来，一旦被打破马上崩。
  • 构造即校验：对象在构造时就保证自己处于合法状态，构造不出来就抛错，而不是造出一个半残对象。
  • Java 集合的 fail-fast 迭代器：遍历过程中集合被并发修改，立刻抛 ConcurrentModificationException，而不是返回不可预期的结果（这一面在 failover / failfast / failback / failsafe 一文里也有提到）。
  • 编译器：源码有语法错误就停止编译并报错，绝不会「跳过有问题的函数、把剩下的编译出来」。
  • 构建工具 / 静态站点生成器：比如 Hugo，只要有一篇文档的 front matter 解析失败，就会中止整站构建——这正是我这个博客踩过的坑，记录在 一次构建失败导致的「假性停更」。

下面是一个最朴素的 fail-fast 校验：

// fail fast: reject the bad input right at the boundary
public void transfer(Account from, Account to, long amount) {
    if (from == null || to == null) {
        throw new IllegalArgumentException("account must not be null");
    }
    if (amount <= 0) {
        throw new IllegalArgumentException("amount must be positive: " + amount);
    }
    // ... safe to proceed; state is known-good from here on
}

为什么这么设计

fail-fast 背后的判断是：带着错误状态继续运行，比直接失败更危险。

  • 错误离源头越近，定位和修复越便宜；流得越远，调试越痛苦。
  • 一旦坏状态扩散（写进缓存、落库、发给下游），破坏就可能不可逆，甚至悄悄产出错误数据而没人发现。
  • 「构建期 / 启动期就失败」好过「运行期随机失败」。前者是确定的、可复现的，能在 CI 阶段就被作者拦下；后者往往在生产环境、在最不该出问题的时候冒出来。

以 Hugo 为例就能看清这种取舍：它把整个站点当成一次编译产物，页面之间有列表、分类、交叉引用等依赖，都要读每篇的 front matter。如果允许「跳过解析失败的那篇、其它照常渲染」，结果会是列表悄悄缺一篇、分类计数对不上、引用断裂——构建却显示成功。这种「静默残缺」比直接报错糟糕得多。于是 Hugo 选择 fail-fast：一篇坏，整站停。代价是「一篇标题写错，全站都不更新」，但好处是它绝不会把一个不完整、不一致的站点悄悄发布出去。

边界：fail-fast 不等于「到处崩」

fail-fast 容易被误读成「让程序遇事就崩」，这是误解。它讲的是在合适的层面、尽早地把错误显性化，而不是让面向用户的服务因为一个坏请求就整个挂掉。

  • 对内 fail-fast，对外有韧性：一个在线服务内部应当对非法状态 fail-fast（尽早抛错、不带病运行），但在系统边缘要做好容错——单个请求出错就返回错误响应、记录日志、必要时熔断降级，而不是让整个进程崩溃。这跟 fail-safe（失效安全）/ fault-tolerant（容错）是互补关系，不是对立。
  • 失败要可见：fail-fast 的价值在于「被看见」。如果错误被 fail-fast 抛出，却被一个空的 catch 吞掉、没有日志没有告警，那等于白失败——这次博客的坑就是构建确实 fail-fast 了，但失败是静默的（站点还停在旧版本、没人收到通知），所以我后来补了构建失败邮件告警，让「快速失败」真正变成「快速知道」。
  • 区分可恢复与不可恢复：对可预期、可恢复的情况（用户输入错误、网络抖动）应优雅处理；fail-fast 主要针对的是「程序员的错误 / 不该发生的状态」——这类问题越早炸出来越好。

和相关概念的关系

  • fail-safe / fault-tolerant：出错时尽量不造成伤害、继续提供（可能降级的）服务；与 fail-fast 是「暴露错误」与「容忍错误」两种取向，常在不同层面同时使用。
  • YAGNI：同属一类「关于纪律的工程原则」。YAGNI 管「别做现在不需要的」，fail-fast 管「别让错误状态继续跑」。
  • 断言、契约式设计（Design by Contract）：把前置 / 后置条件显式化，是 fail-fast 的常见落地方式。

说到底，fail-fast 是一种关于「时机」的纪律：把失败的时间点尽量提前到离错误最近的地方。早一点失败、响一点失败，省下的是后面成倍的排查成本。