第8章：防御式编程

为什么需要防御式编程

想象一条只有一个入口的仓库：门卫检查来货，仓库内部检查货架是否仍然稳定，出了问题还要把损坏箱子隔离。没有这些检查，坏箱子可能一路传到出货口，最后才以“库存不对”的形式爆炸；真正的损失已经发生，责任也很难追溯。

程序同样会收到错误格式、越界数值、过期状态和意外故障。防御式编程要做的不是让程序假定世界永远正确，而是把每一种假设放在离它最近的地方检查，并让失败留下下一层能够处理的含义。

核心合同：安全结果从哪里来

本章用一条可观察合同串起目录中的各个节点：

这个式子在说：安全结果同时需要输入被验证、内部不变量没有被破坏、失败被限制在可处理范围内；只满足其中一项仍然不够。

这里的 信任边界 不是一堵固定的墙，而是一个责任位置：网络请求、文件读取、用户界面和插件调用都可能是边界。边界外的坏数据应该被拒绝或转成明确错误，边界内的“不可能发生”则应该暴露给开发者。

先找出故障会在哪里变红

8.1 保护程序免遭无效输入数据的破坏

外部数据不等于恶意数据：拼写错误、旧版本客户端、截断文件和竞态都可能制造无效输入。边界检查要验证类型、格式、范围、关联关系和编码，并在拒绝之前说明对象、输入和理由。不要只检查“字段存在”；存在但不满足业务约束的值仍然需要拒绝。

验证应靠近数据进入的位置，但不要把所有规则塞进一个巨大的入口函数。语法检查、业务规则和持久化约束可以分层，每一层都留下自己的失败含义。这样，调用者既不会把坏数据当成正常数据继续，也不会把内部实现细节泄露给用户。

8.2 断言

断言适合表达“如果这里失败，说明程序或它的内部协作者已经违反合同”。例如，排序函数返回后应保持序列有序，状态机转移后状态应属于允许集合，缓存索引应指向当前版本。断言不是通用的用户输入处理器；它的价值在于让不可能状态尽早、就地、带上下文地暴露。

建立自己的断言机制

一个可维护的断言机制至少要记录条件、位置、相关标识和当前状态摘要；测试环境可以中止并让问题尽快暴露，产品环境则按照风险决定记录、降级或隔离。无论策略如何变化，断言都不应偷偷改变核心业务结果，否则“检查”会变成另一个副作用来源。

使用断言的指导建议

先问“这个条件是调用者可以修复的输入错误，还是实现者必须修复的内部破坏”。前者应返回明确结果，后者适合断言。不要把断言写成永远为真的装饰，也不要依赖移除断言后的副作用；断言应该帮助定位，而不是成为业务逻辑不可见的前置步骤。

8.3 错误处理技术

错误处理首先要回答三个问题：失败发生在哪里，状态是否已经改变，调用者下一步能做什么。错误码、结果对象和异常都可以表达这些信息，关键是一个边界内保持一致。false、空值或一个通用异常如果无法区分重试、修正输入和人工介入，就不是完整的错误合同。

健壮性与正确性

健壮性不是“遇到任何错误都继续”，正确性也不是“只处理理想输入”。对可预期错误，程序应保持不变量并给出可恢复结果；对不可恢复的内部破坏，程序应快速暴露并阻止坏状态扩散。把二者混成静默降级，会同时损害可用性和诊断能力。

高层次设计对错误处理方式的影响

模块边界决定了谁拥有恢复责任。一个有事务边界的服务可以回滚后返回可重试错误；一个纯转换函数可能只需返回解析失败；一个顶层入口可以把内部信息映射成用户能理解的提示。错误策略不是底层函数各自猜出来的，而要从更高层的状态和责任分配推导出来。

8.4 异常

异常适合穿过多层调用栈传递“当前层不能处理、上层可能处理”的失败，但它不能替代所有分支。抛出异常前要明确对象是否已改变、资源是否会释放、调用者是否能重试；捕获异常时要么补充上下文并转化，要么回滚并转交。捕获后继续执行只能发生在状态已经恢复且合同仍然成立的场景。

8.5 隔离程序以免遭由错误造成的损害

当一段工作无法保证全局状态不被污染时，应把它放入 隔离区。隔离区可以是事务、临时目录、子进程、沙箱或只包含局部副本的对象；它的共同特征是失败不会直接改写系统的长期事实。

隔离区与断言的关系

隔离区负责限制影响范围，断言负责暴露内部不变量。二者不能互相替代：有断言但没有隔离，错误可能已经污染外部状态；有隔离但没有断言，局部失败可能被默默吞掉。一个好的故障路径是“断言发现问题 → 隔离区停止扩散 → 上层依据错误语义选择恢复”。

8.6 辅助调试代码

辅助调试代码的目标是增加证据，而不是增加永久的行为分叉。计数器、轨迹、故障注入和状态快照都应该有清楚的启用条件、成本和移除计划。调试开关如果能改变结果而不是只改变观测，就必须像生产逻辑一样接受测试，否则它会制造第二个只在开发环境出现的程序。

不要自动地把产品版本的限制强加于开发版本之上

开发阶段可以保留更严格的断言、更完整的日志和更短的失败路径，以便问题尽快出现。产品版本可以按安全、隐私、性能和可用性取舍，但“关闭检查”不能成为未经证明的默认动作。先证明哪条检查昂贵、泄露什么以及替代保护是什么，再决定是否调整。

尽早引入辅助调试的手段

越早记录输入摘要、边界决定和状态转移，越容易定位首个偏离。日志应包含稳定的关联标识和版本信息，避免记录密码、令牌等敏感数据。最有价值的调试信息不是“这里失败了”，而是“哪个假设在什么输入下第一次不成立”。

采用冒进式编程

冒进式编程不是忽略风险，而是尽早把假设写成会失败的检查：先让未完成状态、非法范围和错误路径可见，再逐步收紧实现。这样，错误在靠近来源的位置出现，修复范围较小；相反，靠默认值维持表面运行会把故障推迟并扩大。

计划移除调试辅助代码

每一条临时日志或故障开关都应有所有者、用途、成本和移除条件。若它已经变成稳定的安全审计证据，就把它提升为正式能力；若只为一次诊断服务，就在重放通过后删除，避免废弃开关成为无人维护的分支。

8.7 确定在产品代码中该保留多少防范式代码

保留哪些检查要看失败代价、输入可控性、运行环境、性能预算和替代证据。外部边界验证通常属于产品行为；只服务于开发者定位的重型断言和详细快照则可能按构建模式调整。判断标准不是“发布版看起来干净”，而是关闭后是否仍有等价的边界保护、错误记录和恢复路径。

8.8 防御式编程时保持防范

防御不是一次性的条件语句，而是一种持续审视合同的习惯。接口变化时重新核对输入范围和错误语义，重构时重放边界样本，新增依赖时检查它的失败方式，修复缺陷时补上能阻止回归的证据。每次遇到“理论上不会发生”，都要决定是用断言证明它，还是承认它其实可能发生并设计恢复。

其他资源

目录范围以公开中文试读目录和出版社书目信息核对；输入验证、断言语义和安全开发的迁移说明再与 MITRE CWE-20、C++ Core Guidelines 和 NIST SSDF 对照。它们帮助读者把本章的边界思想放进现代工程，不把外部资料冒充原书未公开的具体段落。

先预测，再操作专属机制实验

猜一猜：把无效数据数量调大、打开内部状态故障后，哪个节点会先变红？先选一个节点作为观察点，再只改变一个故障开关；最后点击重置，检查节点、参数、故障状态和结果文字是否回到同一基线。

最小可重放实现

下面的伪代码把防御式编程变成诊断顺序。它不规定某一种语言的异常机制，只规定基线、故障和恢复必须使用同一输入与同一观察窗口：

baseline = run(validInput)
assert baseline.invariant == true
 
fault = run(boundaryInput)
assert fault.errorMeaning == "invalid-input"
assert fault.state == baseline.state
 
resetEnvironment()
assert run(validInput) == baseline

如果 fault 的返回值显示失败，但状态已比基线多出一次写入，修复就没有完成；如果重置后同一输入不能复现基线，则实验还混入了环境残留。记录输入摘要、版本、节点轨迹、错误语义和恢复结果，第二位读者才能复核你的结论。

关键点

• 在信任边界拒绝无效输入，不把默认值伪装成成功。
• 用断言暴露内部不可能状态，用错误结果交给调用者恢复。
• 用隔离区限制损害，用一致的异常边界保留原因链。
• 用辅助调试代码保存首个偏离，并用同一输入重放验证修复。
• 按风险决定产品中保留多少检查，但不能删除最后一道保护。

练习与答案

术语复核

来源与改编边界

本章的章节范围和目录节点来自 《代码大全（第2版）》2006 年中文公开试读目录，作者与版本信息参考 Microsoft Press 官方书页。关于输入验证的安全风险，参照 MITRE CWE-20；关于断言与契约式接口的现代迁移说明，参照 C++ Core Guidelines 和 NIST SSDF。这些资料用于范围、事实和现代实践的独立核对，不代替原书未公开的具体正文。

本页的状态图、故障注入实验、伪代码、练习与答案均为围绕官方目录的独立教学重写；它们不宣称复现原书段落，也不把现代语言规则倒写成 2006 年版的原作结论。