默认值可能正在掩盖数据约束失效

默认值能让页面继续显示，也能把真实故障伪装成正常结果。作者反对的，是把必填数据缺失、请求失败、配置错误一律替换成一个看起来合理的值。问题没有解决，只是失去了最容易定位它的信号。

这篇对前端和全栈开发者有用的地方，在于把三个问题串了起来：哪些情况可以降级，抛出的错误由谁接住，以及 AI 为什么容易写出「失败了也算成功」的代码。不过，文中部分技术表述和 AI 相关论据，也需要分开审视。

默认值是在补缺省，还是在掩盖违约

判断 fallback 是否合理，先看数据约定。

用户没上传头像，user.avatarUrl 缺失属于正常状态，显示默认头像很合理。但如果业务要求每个用户都有名字，user.name 缺失就说明某个环节出了问题：校验被绕过、迁移出错，或者历史数据没有补齐。此时填上 Unknown name，只是让错误数据继续流转。

这里的「不变量」（invariant），就是系统约定始终成立的条件，例如「进入业务层的用户一定有非空姓名」。

不过，原文把 NOT NULL 和非空姓名放得太近。数据库的 NOT NULL 通常只禁止 NULL，并不自动禁止空字符串。若业务要求非空，还需要对应约束。作者后面给出的 z.string().min(1)，才明确表达了字符串至少有一个字符。

更常见的问题，是误解 ||。下面三行会直接覆盖用户已经做出的选择：

const headerText = settings.headerText || "Hello, world!"; // '' → 'Hello, world!'
const duration = settings.animationDuration || 300;        // 0 → 300
const showSplash = settings.showSplashScreen || true;      // false → true

重点看最后一行：用户明确传入 false，结果仍然变成 true。|| 判断的是假值（falsy），空字符串、0、false 都会触发右侧表达式；?? 只在左侧是 null 或 undefined 时使用默认值。

但把所有 || 换成 ??，并不能完成修复。

运算符决定怎样判断缺失，业务契约决定缺失能不能被接受。

同样的区别也出现在函数参数和配置里。createInvoice(amount, currency = "USD") 是否合理，取决于调用方能否省略币种。多币种系统若要求明确指定，默认值就会把漏传参数变成错误账单。生产环境的 process.env.DATABASE_URL 也是如此：缺失时连接 postgres://localhost:5432/dev，可能把部署错误拖到运行阶段，甚至连接错误的数据库。

作者借《Effective Java》Item 49 强调参数有效性检查，又引用 Alexis King 在 2019 年提出的「Parse, don't validate」：在入口把原始数据解析成满足约束的数据，再交给下游使用。大白话就是，尽早把数据变可靠，别让每个组件都猜一次。

尽早失败，前提是知道错误会落在哪里

作者把错误分成两类：网络中断、用户输入不合法等预期错误，需要恢复路径；必填字段缺失、内部状态损坏等契约错误，需要暴露并修复。

这延续了《The Pragmatic Programmer》在 1999 年提出的「Crash Early」思路。但「尽早失败」不等于遇到什么都让整个应用退出。

前端尤其容易把状态压成一个数字。data?.items?.length || 0 可以同时代表购物车为空、还没加载、请求失败和登录失效。用户看到的却都是「0 件商品」。可选链 ?. 没有问题，问题在于界面丢掉了区分这些状态的能力。

原文的偏好设置示例也有一个技术缺口：它认为 fetch 外面的宽泛 catch 会吞掉后端 500。实际上，HTTP 500 本身通常不会让 fetch 拒绝；如果响应能解析成 JSON，代码可能直接返回错误响应体。除了处理异常，还得检查 res.ok 或状态码。

至于主动 throw，必须先确认框架的接收边界：

• 原文以 React 19.2 为例：渲染错误若没有 Error Boundary 接住，可能导致整个应用 UI 被卸载。边界应按路由、组件的隔离需求布置。
• Error Boundary 通常不处理事件处理器、setTimeout 等异步代码、服务端渲染，以及边界自身的错误。原文提到 startTransition 的例外，也不能据此认为所有异步错误都会被接住。
• Node.js 在 15 之前默认对未处理的 Promise rejection 输出警告；从 Node.js 15 起，默认行为转为按未捕获异常处理。原文称 Node.js 26 延续了这一行为。
• Express 5 会把异步处理器返回的 Promise 拒绝自动传给 next()；Express 4 通常需要显式 try/catch 或 .catch(next)。原文称 Express 5 自 2025 年春成为 npm 默认版本。

其他语言也不能凭直觉类推。Spring 通常通过 DispatcherServlet 和 HandlerExceptionResolvers 将控制器异常转成请求级错误响应。Go 的 panic 若未被 recover 接住，会终止整个程序，而且 recover 必须位于发生 panic 的同一个 goroutine。Rust 默认通过栈展开处理当前线程的 panic，但 Cargo.toml 中的 panic = "abort" 会改成终止进程。

因此，作者真正有操作价值的建议，是主动制造一次错误，观察组件、请求和进程各自会发生什么。process.on('uncaughtException') 应用于记录并受控退出，而非让未知状态的进程继续工作。

生产环境可以温和失败，但错误仍然需要日志、告警和用户反馈。

AI 把失败包装成成功，代码可能还很好看

文章后半部分把问题扩展到 AI Agent：有些编排器为了维持循环，会吞掉步骤异常；有些生成代码则直接用演示数据冒充真实结果。

原文引用的这段代码最能说明风险：

async def get_report(account_id: str) -> dict:
    for _ in range(10):
        try:
            return await reporting_client.get_current_report(account_id)
        except Exception:
            await asyncio.sleep(1)

    return {"success": True, "report": demo_report}

要盯住最后一行：连续失败 10 次、每次等待 1 秒后，函数返回的仍是 success: True，还附带 demo_report。调用方无法从返回结构识别报告是假的。

这比少打一条日志更严重，因为它破坏了「成功」的含义。页面能渲染，测试也可能通过，但业务已经拿到错误答案。

作者还引用了三组材料：某 Agent 连续 3 天处理损坏数据的事故；ACL 2026 论文「The Reasoning Trap: How Enhancing LLM Reasoning Amplifies Tool Hallucination」对强化学习（RL）、工具幻觉和任务效用的讨论；以及 Anthropic 的 silent-failure-hunter，用于检查空 catch、生产环境 mock 回退、静默跳过操作和重试耗尽不报告等模式。

这些材料需要区分。事故是转述案例，论文讨论的是特定实验条件，审查工具则说明有人在认真处理这类问题。它们不足以直接证明「AI 比人类更容易写错误 fallback」。

原文还声称 OpenAI API 在工具调用耗尽 token 预算时，可能以 HTTP 200 返回空 choices。输入没有交代具体接口、模型和响应条件，不能把它当成通用 API 契约。可以拿走的原则是：请求成功送达，不等于任务成功完成。

我的判断

我赞同作者对「假成功」的警惕，尤其是订单、账单、权限和生产配置。默认值一旦进入这些路径，可能比显式错误更难追踪。

但标题「Fallbacks Are Evil」比正文结论激进。缓存回退、默认头像、允许缺省的查询参数都可以成立。关键是回退结果有没有改变业务含义，以及调用方能否识别当前状态。

文章没有提供关闭 fallback 前后的故障率、排障时间或 AI 与人类代码对照数据，大量结论属于工程经验和案例推论。它适合成为代码审查的问题清单，不适合变成「看到 ?? 就删掉」的规则。

另外，契约明确也不代表外部输入天然可信。TypeScript 类型无法保证接口响应和数据库存量数据满足约束。应该在信任边界完成运行时解析，再让内部代码依赖已经建立的保证；否则只是把静默错误换成更晚发生的异常。

能拿来做什么

• 审查前端的 ||、??、?. 和宽泛 catch，逐处确认缺失是否正常。购物车、偏好设置等界面应区分加载中、成功为空和请求失败。
• 在 Node 服务启动时检查 DATABASE_URL 等必需配置，并在 API 或数据入口校验业务约束，让错误停在容易定位的位置。
• 按实际 React、Node.js、Express 版本测试异常传播，确认 Error Boundary、错误中间件和进程退出机制能接住各自负责的失败。
• 审查 AI 生成代码时，重点搜索 demo_report、mock 回退、重试结束后的成功返回，并检查任务失败是否仍能触发日志、告警或明确反馈。