24 死掉的程序不会说谎

为什么这一单元不可压缩

想象仓库管理员发现一箱货物的标签已经脱落。如果他把箱子照常入库、扣减库存，再通知下一站“货已确认”，最后谁也说不清问题从哪里开始。真正可靠的做法是先停在入口，保留箱号、货物和当时看到的状态，再决定怎样重新核对。

程序也会遇到同样的瞬间：一条记录不再满足自己的前提，但后面的代码仍可能把它当成正常结果。让程序及时停下并把现场说完整，定位成本才不会随着传播路径一起增长。

本页依据 David Thomas、Andrew Hunt《程序员修炼之道：通向务实的最高境界（第2版）》，云风译，电子工业出版社，2020年4月，ISBN 9787121384356 的公开完整中文目录，独立重构 24 死掉的程序不会说谎 与 提示38：尽早崩溃。示例、代码、图示、实验和练习均为本课程重新设计，不复制原书正文、插图或答案。

先看会翻车的路径

下面的实验把一个本应为正数的订单数量改成 NaN。请先猜一猜：如果校验被跳过，错误会先污染“写入状态”还是“通知下游”？再逐步推进，观察程序在哪个节点还来得及把现场交出来。

常见误区与回退

关键模型：让程序在第一处不可信边界停下

24 死掉的程序不会说谎

这一单元讨论的是一种可观察的故障处理习惯，而不是“崩溃越多越好”。先定义 <Term def="在关键假设不成立时立即拒绝继续执行，并把失败上下文交给调用者或日志的策略。">快速失败</Term>：它把停止点放在错误刚出现、还没有污染持久状态的位置。对于 amount = NaN，正确结果不是悄悄变成 0，而是明确拒绝这次请求。

快速失败的价值有两层。第一，错误不会继续伪装成成功，调用者能立刻采取动作；第二，异常还靠近源头，记录的上下文比经过多个服务后的最终症状更完整。它并不替系统完成恢复，也不意味着所有异常都要让进程退出；边界的关键是拒绝继续执行当前不安全路径。

提示38：尽早崩溃

“尽早崩溃”把上面的习惯推进到工程边界：发现关键假设被破坏时，宁可暴露失败，也不要让后续步骤猜测。这里的“早”指第一处能证明数据不可信的位置，而不是任意更早地结束整个服务。

当系统报告失败时，先检查它是否仍携带 <Term def="已经不能按正常路径解释、验证或安全写入的输入、状态或结果。">不可信状态</Term> 的证据。请求 ID、原始输入、当前节点和状态快照让复核者知道“谁在什么时候看到了什么”，而不是只看到一个抽象的错误码。

五节点证据链

把失败处理拆成五个连续节点：异常负责暴露问题，上下文负责说明现场，停止负责切断当前路径，隔离负责阻止坏结果被接收，恢复负责从可信输入重建。先看一遍图，再用 Stepper 逐段对照；每个箭头传递的都是“可复核证据”，不是一句“继续”。

异常：在假设破坏处留下信号

解析结果为空、类型不对、权限失效或状态版本不匹配，都属于应被显式处理的异常。异常本身不是上下文；它只是告诉我们某个前提不再成立。处理函数必须保留失败来源，不能用普通返回值把差异抹平。

上下文：让失败可以被复核

上下文至少包含请求身份、输入的原始形状、当前节点、状态快照、代码版本和拒绝原因。它回答“哪一个对象在什么状态下被拒绝”。这份记录应该在边界处生成，而不是等全链路结束后再从零散日志拼出来。

停止：不要越过安全写入点

当校验发现 <Term def="错误结果沿着正常控制流或事件流被后续节点继续消费的现象。">错误传播</Term> 时，停止意味着当前调用不再写入、不再返回成功，也不再触发后续副作用。停止点越靠近首次失真，回退范围通常越小；但事务和并发语义仍需由真实系统决定。

隔离：把不可信结果挡在故障边界外

不写入还不够，因为另一个进程可能已经看到缓存、消息或临时文件。用 <Term def="不可信状态被拒绝接收、不会继续影响其他组件的明确交接位置。">故障边界</Term> 标出谁可以看到什么：失败响应可以交给调用者，未确认的订单事件不能交给结算服务，坏缓存不能成为下一次读取的事实来源。

恢复：从可信输入而不是最后症状重建

恢复不是手工把最后一条记录改成“成功”。先保存 <Term def="故障后重新建立可信状态的一组可执行步骤，包括回退、重放、人工接管和验证。">恢复策略</Term>，再决定回退中间写入、隔离消息或从原始输入重放。重放前要确认幂等键、版本和外部副作用的边界，否则修复会制造第二个问题。

三步把原则改成代码行为

每一步先写预测，再推进同一个 order-42。只改变“快速失败是否开启”这一项，其他输入和起始状态保持一致；实际首差不同于预测时，保留差异，不用最终结果反推原因。

代码对照：拒绝不可信数量

先把失败和成功写成两种明确的结果形状。调用者得到的不是一个需要猜测含义的默认值，而是可以携带上下文的拒绝。

type ParseResult =
  | { ok: true; amount: number }
  | { ok: false; reason: string; raw: string };
 
function parseAmount(raw: string): ParseResult {
  const amount = Number(raw);
  if (!Number.isInteger(amount) || amount <= 0) {
    return { ok: false, reason: "amount must be a positive integer", raw };
  }
  return { ok: true, amount };
}

这里的判断把 NaN、小数和非正整数都挡在持久化之前。生产代码还要把请求 ID、当前状态版本和错误来源加入日志；reason 只是给调用者看的最小解释。

下一段展示边界如何切断副作用。若真实项目需要跨服务事务，应把这条边界改写成可靠消息或补偿协议，但不能省略“未确认就不通知”的事实。

function createOrder(requestId: string, rawAmount: string) {
  const parsed = parseAmount(rawAmount);
  if (!parsed.ok) {
    return { ok: false, requestId, reason: parsed.reason, raw: parsed.raw };
  }
 
  const order = reserveStock(requestId, parsed.amount);
  if (!order.ok) return { ok: false, requestId, reason: order.reason };
  publishOrderConfirmed({ requestId, orderId: order.id });
  return { ok: true, requestId, orderId: order.id };
}

publishOrderConfirmed 只出现在库存操作成功之后。若库存操作在内部产生了部分变化，恢复边界必须由事务、幂等键或补偿动作明确负责；不要把“函数返回失败”当作状态已经自动恢复。

正常、边界与一项故障

边界样本的价值在于固定“能否接受”的口径；故障样本的价值在于证明停止点确实有保护作用。三次运行共享代码版本、请求身份和起始状态，复核者才能把差异归因给唯一条件。

记录首差，而不是只记录结局

用 <Term def="在预期运行与实际运行之间最早出现的可验证差异；它帮助复核者定位停止、传播或恢复的责任边界。">首差</Term> 取代“最终失败”作为诊断起点。一个有用的记录可以写成：requestId=order-42、node=validate、expected=positive integer、actual=NaN、downstreamCalls=0、recovery=replay-original。

首差必须能回答四件事：哪个对象先失真，哪个节点本来应该停止，是否已经发生持久副作用，修复后如何重放。若日志只保存堆栈顶层或 HTTP 500，复核者仍无法判断错误是否已经传播。

本章回顾

• 快速失败让错误在第一处不可信边界暴露，而不是被默认值包装成成功。
• 上下文把对象、状态、请求身份和拒绝原因交给复核者。
• 停止与隔离共同阻断写入、缓存和事件向下游传播。
• 恢复从原始输入重放，保留首差和未覆盖边界，不手工篡改结局。

练习：让“停止”成为可验收的代码行为

名词解释

来源与改写范围

• 作者与英文版页面：核对 20 周年版书名、版本与 Topic 24 的英文目录坐标。
• 中文公开目录：核对“24 死掉的程序不会说谎”与“提示38：尽早崩溃”的中文目录位置。
• 本页是基于公开目录的 independent rewrite；故障链、TypeScript 示例、图示、实验和练习均为本课程重新设计，不声称提供原书全文或原书答案。

前后导航

• 上一页：23 契约式设计
• 下一页：25 断言式编程