与Assert断言的配合使用)
从“事后Debug”到“事前防御”：C#代码契约与断言的协同防御体系
在软件开发中，错误处理通常被分为两个阶段：开发时的预防和运行时的捕获。大多数开发者熟悉后者——通过异常处理、日志记录和断言(Assert)在运行时捕获问题。但更资深的工程师会追求前者：在代码执行前就尽可能消除潜在错误。这就是代码契约(Code Contracts)与断言配合使用的核心价值。
1. 防御性编程的层次化架构
防御性编程不是单一技术，而是一套分层体系。最底层是编译器的静态检查，中间层是代码契约的编译时验证，最上层才是运行时的断言和异常处理。这种分层设计让错误在最早可能的阶段被捕获。
典型的防御层次：
- 编译时静态检查（类型安全、空引用检查等）
- 代码契约验证（前置条件、后置条件、对象不变量）
- 运行时断言检查（Debug.Assert）
- 异常处理（try-catch）
在C#生态中，微软的Code Contracts库和Debug.Assert分别代表了第二层和第三层的典型实现。它们不是竞争关系，而是互补的防御机制。
2. 代码契约：编译时的防御工事
代码契约通过三种主要契约类型在编译期建立防御：
2.1 前置条件(Requires)
前置条件定义了方法对输入参数的约束。与运行时参数检查不同，它能在调用方编译时就发现问题。
public int CalculateDiscount(Customer customer) { Contract.Requires(customer != null); Contract.Requires(customer.Age >= 0); // 方法实现 }提示：在Visual Studio中启用静态检查器后，违反Requires的代码会直接产生编译警告。
2.2 后置条件(Ensures)
后置条件保证方法执行后的状态，包括返回值和对象状态。
public int Withdraw(int amount) { Contract.Ensures(Contract.Result<int>() >= 0); Contract.Ensures(balance >= 0); // 取款逻辑 }2.3 对象不变量(Invariant)
定义对象在整个生命周期中必须保持的状态：
[ContractInvariantMethod] private void ObjectInvariant() { Contract.Invariant(this.balance >= 0); Contract.Invariant(this.owner != null); }3. 断言：运行时的最后防线
虽然代码契约能在编译期捕获大量问题，但有些条件只能在运行时验证。这就是Assert的价值所在：
3.1 何时选择Assert而非契约
| 场景 | 适合技术 | 原因 |
|---|---|---|
| 输入参数基本验证 | Code Contracts | 调用方早期发现问题 |
| 复杂业务规则验证 | Assert | 可能依赖运行时状态 |
| 算法中间状态检查 | Assert | 编译时难以静态分析 |
| 第三方服务响应验证 | Assert | 外部系统行为不可预测 |
3.2 Assert的进阶用法
除了简单的参数检查，Assert可以验证更复杂的业务不变量：
public void ProcessOrder(Order order) { // 契约验证基本条件 Contract.Requires(order != null); // 业务逻辑... // 断言验证复杂不变量 Debug.Assert( order.Status != OrderStatus.Complete || order.Payment != null, "已完成订单必须有支付记录"); }4. 实战：API参数验证的协同防御
让我们通过一个Web API参数验证场景，展示两种技术的完美配合：
4.1 分层验证策略
- DTO结构验证：通过Code Contracts确保基本结构
public class CreateUserRequest { [Required] public string Username { get; set; } [Range(18, 100)] public int Age { get; set; } [ContractInvariantMethod] private void ObjectInvariant() { Contract.Invariant(Age >= 18 || Username == null); } }- 业务规则验证：通过Assert检查运行时条件
public IActionResult CreateUser([FromBody] CreateUserRequest request) { // 契约已确保基本有效性 // 检查用户名唯一性（需要数据库查询） var exists = _userRepository.Exists(request.Username); Debug.Assert(!exists, "用户名应该已被前置检查过滤"); // 复杂业务规则 Debug.Assert( !(request.Age < 21 && request.Username.Contains("admin")), "未成年人不能创建管理员账号"); }4.2 性能考量
在Release构建中，Debug.Assert会被移除，而Code Contracts可以通过重写工具保持运行时检查。这种差异使得两者可以这样分工：
- Code Contracts：用于关键不变量，即使在生产环境也保留
- Debug.Assert：用于开发阶段的辅助检查，不影响生产性能
5. 工具链集成与团队实践
要实现这套防御体系的最大价值，需要正确的工具配置和团队规范：
5.1 开发环境配置
- 安装Code Contracts工具集
- 在项目属性中启用运行时检查
- 配置静态检查器警告级别
- 设置持续集成中的契约验证
5.2 代码审查清单
在审查使用契约和断言的代码时，检查：
- 是否所有公共方法都有明确的前置条件
- 关键对象是否定义了不变量
- Assert是否用于真正的运行时检查而非参数验证
- 契约条件是否过于复杂影响可读性
5.3 常见反模式
- 契约滥用：在内部方法上过度使用契约
- Assert依赖：用Assert替代正常的错误处理流程
- 条件重复：在契约和Assert中检查相同条件
- 模糊条件：使用难以理解的布尔表达式
在大型项目中，我们通常会建立契约使用指南，规定哪些模块需要严格契约，哪些场景适合使用Assert。例如，核心业务逻辑优先使用契约，而插件系统更适合运行时断言。
