你必须修复你的断言 (Zig)

背景

在讨论平台（如 Hacker News）上，一位用户提出了一个常见观点：“在生产环境中禁用断言（asserts）是一种相当普遍的技术，对吧？”

作者认为，虽然这句话在某种程度上是事实，但这是一种“无可救药的糟糕实践”。这一讨论的起因是 Zig 语言中 std.debug.assert 的工作方式。作者希望通过深入分析断言在编程语言中的角色、Zig 的具体实现机制以及构建模式的影响，来反驳“在生产环境禁用断言”这一惯例，并阐述为什么保留断言对于软件正确性和性能优化至关重要。

核心内容

断言的一般概念与作用

断言（Assert）是代码中的一行指令，用于向程序引入一个新的事实或约束。例如：“这个参数永远不会为空”或“这个整数永远不会是偶数”。其语法通常如下：

assert(my_arg != null);
assert(my_num % 2 != 0);

如果编程语言的类型系统能够强制执行此类约束（例如 Zig 中的普通指针 *Foo 永远不为空，而可选指针 ?*Foo 可以为空但强制检查），则应优先使用类型系统而非断言。

断言的主要用途是显式声明代码的前置条件、后置条件和不变量。良好的断言比单元测试更能保护代码免受编程错误的影响，尤其是在进行模糊测试（fuzzing）时。作者强调：“一个断言抵得上一千个单元测试，如果结合模糊测试，其价值更是高出几个数量级。”

Zig 中的断言机制

Zig 中的断言基于 unreachable 这一语言特性，该特性用于标记无效的代码路径。

1. 代码路径优化示例

const Op = enum { a, b, c };
fn execute(orig_op: Op) void {
    var op = orig_op;
    if (op == .a) {
        op = .b; // 将 .a 转换为 .b
    }
    const op_cost = switch(op) {
        .a => unreachable, // 不可能到达
        .b => 50,
        .c => 100,
    };
    // 完成 op 的处理
}

在上述示例中，if 语句确保 .a 始终被转换为 .b。因此，当执行到 switch 语句时，进入 .a 分支是不可能的。unreachable 不仅可以作为语句，还可以作为表达式使用，无需为不可能发生的情况提供 awkward 的占位值。

2. std.debug.assert 的实现 Zig 的标准库断言函数利用 unreachable 实现：

pub fn assert(ok: bool) void {
    if (!ok) unreachable; // 断言失败
}

构建模式与未定义行为

Zig 提供多种构建模式，且这些模式可以针对不同依赖项或代码块进行细粒度控制：

• Debug
• ReleaseSafe
• ReleaseFast
• ReleaseSmall

当断言触发时，会发生“非法行为”（illegal behavior）：

• 检查模式（Checked modes，如 Debug、ReleaseSafe 或启用 @setRuntimeSafety(true)）：保证程序通过 panic 崩溃。
• 未检查模式（Unchecked modes，如 ReleaseFast、ReleaseSmall 或 @setRuntimeSafety(false)）：导致“未检查的非法行为”（Unchecked Illegal Behavior, UIB）。

在未检查模式下，程序可能会表现出错误的行为。例如，编译器可能会生成“穿透”（fallthrough）的代码，或者完全省略某些比较逻辑以进行优化。虽然这可能导致程序行为异常，但这是编译器进行激进优化（如消除分支）的基础。这种优化对视频游戏和其他实时媒体应用至关重要。

Zig 断言不是宏

对于 C/C++ 开发者而言，Zig 的 std.debug.assert 是一个普通函数而非宏，这带来了显著差异：

1. 副作用安全：在 C/C++ 中，禁用断言通常意味着整个 assert 调用（包括参数中的表达式）被注释掉。因此，C/C++ 中严禁在断言中使用带有副作用的表达式。而在 Zig 中，函数参数在调用前会被求值，因此可以安全地放置带有副作用的表达式：

   // 断言移除操作不是空操作：
   assert(my_map.remove("expected-to-exist"));
   

2. 性能考量：由于参数总是被求值，如果断言依赖复杂的计算，即使在未检查模式下，这些计算也可能不会被省略。此时，开发者需要使用 comptime if 来根据构建模式保护代码：

   const builtin = @import("builtin");
   if (builtin.mode == .Debug) {
       var condition = ...;
       // 计算条件所需的任何簿记
       assert(condition == .ok);
   }
   

生产环境禁用断言的弊端

作者总结了处理断言的三种方式：

1. 保留为运行时检查，触发时 panic。
2. 利用断言进行性能优化，接受断言错误时程序行为异常的风险。
3. 完全禁用断言（Zig 默认不支持，但可自定义实现）。

作者认为第 3 种方式（完全禁用）是“无可救药的糟糕选择”。禁用断言的理由通常是否定前两种：

• 不想保留运行时检查（因性能开销或避免崩溃）。
• 不信任断言的正确性，害怕程序行为异常。

然而，禁用断言意味着当“假设不可能”的条件实际发生时，程序不会崩溃，而是继续在错误的假设下运行。这本身就是一种程序行为异常（misbehavior），即使它不是由上述的 UIB 引起的。

虽然有人可能认为未定义行为（UB/UIB）比运行时断言失败更危险，但作者反驳道：在足够复杂的软件中，即使没有 UIB，错误的假设也足以扭曲程序逻辑。在运行时伪造断言条件，本质上就是偏离了规范。

关键要点

• 断言优于单元测试：精心设计的断言能比单元测试更有效地捕捉编程错误，特别是在模糊测试场景下。
• Zig 的 unreachable 是优化利器：Zig 利用 unreachable 标记无效代码路径，允许编译器进行非局部的激进优化（如消除分支），这对高性能应用（如游戏）至关重要。
• 构建模式决定行为：
  • 在 Debug/ReleaseSafe 模式下，断言失败会导致程序崩溃（Panic），确保错误被立即发现。
  • 在 ReleaseFast/ReleaseSmall 模式下，断言失败可能导致未定义行为（UIB），但这换取了更高的执行效率。
• 函数式断言避免宏陷阱：Zig 的断言是普通函数，参数总是被求值。这使得在断言中使用带有副作用的表达式成为可能且安全，但也意味着复杂计算不会自动被优化掉，需手动使用 comptime if 控制。
• 禁用断言并非良策：完全在生产环境禁用断言会导致程序在逻辑错误发生时继续以错误状态运行，这比崩溃更难以调试，且并未真正解决性能或稳定性问题。
• UIB 并非唯一威胁：虽然未定义行为（UIB）危险，但断言失败导致的逻辑偏离规范同样会导致严重的程序扭曲，不应通过禁用断言来掩盖潜在的错误假设。

意义与影响

这篇文章深刻揭示了现代系统编程语言（如 Zig）在内存安全、性能优化和调试便利性之间的权衡。它挑战了传统 C/C++ 开发中“生产环境禁用断言”的惯性思维，指出这种习惯往往源于对宏副作用的恐惧，而非对程序正确性的理性考量。

对于 Zig 开发者而言，理解 unreachable 和断言在编译器优化中的核心作用，有助于编写更高效且安全的代码。对于更广泛的软件工程领域，文章强调了一个重要原则：程序在错误假设下的静默运行（Silent Failure）往往比显式崩溃（Explicit Crash）更具破坏性。通过