第21章断言调试

课程目录第21章断言调试

断言调试：运行时断言、静态断言、断言与错误处理

说到调试，有个工具我特别喜欢用——断言。说白了，断言就是代码里的「安检员」。你告诉它「这里绝对不可能是负数」，它就在运行时帮你盯着。一旦越界，立刻报警。

我刚开始写C语言那会儿，觉得断言可有可无。后来在一个通信协议栈的项目里，被一个野指针折磨了三天。从那以后，我写代码必加断言。嗯，真香。

运行时断言：代码里的哨兵

运行时断言，就是 assert() 宏。它长这样：

#include <assert.h>

void process_buffer(char *buf, size_t len) {
    assert(buf != NULL);      // 指针不能为空
    assert(len > 0);          // 长度必须大于0
    assert(len < 1024);       // 防止越界

    // 正常处理逻辑...
    for (size_t i = 0; i < len; i++) {
        buf[i] = toupper(buf[i]);
    }
}

当 assert() 里的条件为假时，程序会立刻终止，并打印出文件名、行号和失败条件。你想想看，这比让程序悄悄崩溃、然后你去翻core dump要友好得多。

核心要点：断言只应该在「绝对不可能发生」的情况下触发。如果某个错误是可能发生的（比如用户输入非法），那就应该用 if-else 做错误处理，而不是断言。

我在项目中遇到过一件事：有个同事在断言里写了函数调用——assert(free_memory() > 0)。结果发布版本里断言被禁用了，那个函数就再也没执行过。嗯，这是个经典坑。

注意：在 Release 版本中，如果定义了 NDEBUG 宏，所有 assert() 都会被预处理器移除。所以：

不要在断言里写有副作用的表达式
不要用断言代替正常的错误处理
断言只用于调试阶段，不依赖它做逻辑判断

静态断言：编译期的守护神

运行时断言有个问题——它只能在程序跑起来之后才检查。有些错误，比如结构体大小不对、数组越界，其实在编译时就能发现。这时候就该 static_assert 出场了。

C11 标准引入了 _Static_assert，C23 里可以直接用 static_assert。用法很简单：

#include <assert.h>

// 检查结构体大小是否符合预期
struct packet_header {
    uint16_t type;
    uint16_t length;
    uint32_t crc;
};

static_assert(sizeof(struct packet_header) == 8,
              "packet_header must be exactly 8 bytes");

// 检查枚举值范围
enum error_code {
    ERR_NONE = 0,
    ERR_TIMEOUT = 1,
    ERR_CRC = 2,
    ERR_MAX = 255
};

static_assert(ERR_MAX <= 255, "error code must fit in uint8_t");

静态断言的好处是：编译不过，代码根本发不出去。我曾经在一个跨平台项目里，因为不同编译器对结构体对齐的处理不一样，导致结构体大小不一致。加上 static_assert 后，换平台编译直接报错，省去了排查的麻烦。

我的习惯：只要定义了结构体、枚举、或者依赖特定大小的数据类型，我都会加一个 static_assert。尤其是做嵌入式开发时，硬件寄存器映射的结构体，大小必须精确无误。

断言与错误处理：什么时候用哪个？

很多新手会问：断言和 if-else 错误处理，到底用哪个？我画了张图，帮你理清思路。

说白了，判断标准就一条：这个错误是「程序员的错」还是「外部环境的错」？

程序员的错（比如传了空指针、索引越界）→ 用断言。因为这是代码逻辑有bug，应该尽早暴露、修复。
外部环境的错（比如文件不存在、内存不足）→ 用错误处理。因为这是运行时可能发生的正常情况，程序应该优雅地处理。

实战经验：我在一个RTOS项目里，任务栈大小是通过配置文件指定的。我在任务创建函数里加了断言：assert(stack_size >= MIN_STACK_SIZE)。结果有一次配置文件写错了，编译通过，但运行到任务创建时直接断言失败。我立刻定位到了问题。如果当时用的是 if-else 返回错误码，可能要在系统跑起来很久之后才能发现。

自定义断言宏：更灵活的调试手段

标准 assert() 功能有限。我习惯封装一个自定义断言宏，加入更多调试信息：

#include <stdio.h>
#include <stdlib.h>

#ifdef DEBUG
    #define ASSERT(cond, msg) \
        do { \
            if (!(cond)) { \
                fprintf(stderr, "ASSERT FAILED: %s\n", msg); \
                fprintf(stderr, "  File: %s, Line: %d\n", __FILE__, __LINE__); \
                fprintf(stderr, "  Function: %s\n", __func__); \
                /* 打印调用栈（嵌入式平台可替换为其他操作） */ \
                abort(); \
            } \
        } while(0)
#else
    #define ASSERT(cond, msg) ((void)0)
#endif

// 使用示例
void configure_timer(int channel) {
    ASSERT(channel >= 0 && channel < 4, "Timer channel out of range");
    // 配置定时器...
}

这个宏的好处是：

可以自定义错误信息，比标准 assert 更清晰
可以加入 __func__ 等额外调试信息
Release 版本下完全消失，零开销

避坑指南：我曾经在自定义断言宏里用了 printf，结果在中断服务函数里触发断言时，printf 导致系统死锁。嗯，从那以后，我在中断里用的断言只做硬件操作（比如点亮LED、触发蜂鸣器），绝不调用任何可能阻塞的函数。

断言的最佳实践总结

场景	推荐做法	原因
函数参数合法性检查	断言（内部调用）错误处理（外部接口）	内部调用出错是bug，外部调用出错是常态
数据结构完整性	断言	链表、队列等结构被破坏，说明有内存越界
硬件寄存器操作	静态断言	寄存器地址、位域定义必须在编译期确定
用户输入验证	错误处理	用户输入不可信，必须做边界检查
资源分配失败	错误处理	malloc 失败、文件打开失败是正常情况
状态机状态检查	断言	进入非法状态说明逻辑有bug

我的个人习惯：每个函数的开头，先用断言检查所有「应该由调用者保证」的条件。然后再用 if-else 处理「可能由外部环境导致」的错误。这样代码的意图非常清晰——哪些是bug，哪些是异常，一目了然。

断言不是银弹。它不能替代完善的错误处理，也不能替代充分的测试。但它是一个极其高效的调试工具。你想想看，与其让bug在代码里潜伏几个月，不如在它出现的第一时间就抓住它。这就是断言的魅力。

嗯，关于断言就聊这么多。记住一句话：断言是给开发者看的，错误处理是给用户看的。两者各司其职，缺一不可。

📚 课程目录

断言调试：运行时断言、静态断言、断言与错误处理

运行时断言：代码里的哨兵

静态断言：编译期的守护神

断言与错误处理：什么时候用哪个？

自定义断言宏：更灵活的调试手段

断言的最佳实践总结