第2章断言的艺术

课程目录第2章断言的艺术

断言的艺术：assert宏、静态断言与生产策略

大家好，我是你们的嵌入式系统讲师。今天我们来聊聊断言——这个看似简单、实则暗藏玄机的工具。

先问个问题：你写过 assert 吗？写过。你真正用好它了吗？嗯，这就未必了。

我在项目中见过太多「assert 滥用」和「assert 缺失」的案例。有人把 assert 当错误处理用，有人干脆不用，还有人生产代码里留着 assert 导致系统崩溃。今天我们就把它彻底讲透。

一、assert 宏：运行时检查的利刃

assert 是 C 标准库提供的宏。它的作用很简单：在调试阶段检查「绝对不应该发生」的条件。

#include <assert.h>

void set_gpio_mode(int pin, int mode) {
    assert(pin >= 0 && pin < 16);   // 引脚号必须在 0~15
    assert(mode == GPIO_INPUT || mode == GPIO_OUTPUT);
    // 实际配置代码...
}

你看，这里 assert 检查的是「调用者传参必须正确」。如果传了非法参数，说明调用方代码有 bug，而不是运行时错误。

核心原则：assert 检查的是「程序内部逻辑错误」，不是「外部输入异常」。

我个人习惯在函数入口处用 assert 检查前置条件。比如指针不能为 NULL、枚举值必须在合法范围内、数组索引不能越界。这些条件一旦不满足，说明代码写错了，应该立刻暴露出来。

我在项目中遇到过这样一个案例：一个电机驱动库，用户传了非法 PWM 通道号，结果写到了相邻内存，导致另一个通道的配置被覆盖。排查了两天才找到根因。如果当时在入口加个 assert，5 分钟就能定位。

二、静态断言 static_assert：编译期就发现问题

运行时 assert 很好，但有些问题可以在编译期就发现。C11 引入了 _Static_assert，C23 中 static_assert 成为关键字。说白了，就是「编译期断言」。

#include <assert.h>

// 检查结构体大小是否符合预期
static_assert(sizeof(MyPacket) == 64, "MyPacket must be exactly 64 bytes");

// 检查枚举值范围
static_assert(MAX_CHANNELS <= 16, "Channel count cannot exceed 16");

// 检查平台特性
static_assert(CHAR_BIT == 8, "Only 8-bit char supported");

为什么要用静态断言？你想想看，如果结构体因为对齐问题实际大小和预期不符，运行时 assert 要到执行到那行代码才能发现。而静态断言在编译阶段就报错，连链接都不让你过。

我的建议：所有与硬件相关的结构体、联合体、位域定义，后面都跟一个 static_assert 检查大小。这是防御式编程的「第一道防线」。

我曾经在一个 ARM Cortex-M 项目里，因为编译器版本升级导致结构体对齐方式变了，一个 60 字节的结构体被填充到 64 字节。幸好有 static_assert 在编译期就报错，否则烧到芯片里才发现，那可就麻烦了。

三、断言与错误处理：本质区别

这是初学者最容易混淆的地方。我画个图帮你理清思路。

看明白了吗？断言和错误处理是两码事。

维度	断言 (assert)	错误处理 (if/return)
检查对象	程序内部逻辑错误	外部环境异常
触发含义	代码有 bug	运行时异常
生产环境	通常关闭 (NDEBUG)	必须保留
恢复方式	终止程序（暴露问题）	优雅恢复或降级
典型场景	指针非空、索引范围、状态机状态	文件打开失败、内存分配失败、通信超时

注意：不要用 assert 检查用户输入、文件是否存在、网络连接是否正常。这些是错误处理的范畴。我曾经见过有人用 assert 检查 malloc 返回值——这是典型的误用。内存分配失败是运行时异常，不是程序 bug。

四、生产环境下的断言策略

到了生产环境，事情就复杂了。assert 在 NDEBUG 宏定义下会被完全移除。这意味着：

// 调试版本：assert 生效
// gcc -DDEBUG main.c

// 生产版本：assert 被移除
// gcc -DNDEBUG -O2 main.c

但问题来了：生产环境真的不需要断言吗？

我个人认为，完全移除断言是危险的。尤其是嵌入式系统，有些 bug 在调试环境下不会复现，到了生产环境才暴露。如果断言被完全移除，你连问题发生的线索都没有。

我建议的策略是这样的：

调试阶段：标准 assert 全开，发现问题立即终止
测试阶段：保留关键断言，但改为日志记录 + 系统重置
生产阶段：保留「安全断言」，触发时记录错误信息并尝试恢复

具体怎么做？我们可以自定义一个断言宏：

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

// 生产环境下的安全断言
#define ASSERT_SAFE(cond, msg) do { \
    if (!(cond)) { \
        log_error("Assertion failed: %s, file %s, line %d", \
                  msg, __FILE__, __LINE__); \
        /* 触发看门狗复位或进入安全模式 */ \
        system_reset(); \
    } \
} while(0)

// 使用示例
void process_data(uint8_t *buf, size_t len) {
    ASSERT_SAFE(buf != NULL, "buf cannot be NULL");
    ASSERT_SAFE(len > 0 && len <= MAX_BUF_SIZE, 
                "len out of range");
    // 处理数据...
}

我的经验：在嵌入式项目中，我通常保留三类断言：

致命断言：触发后系统无法继续，直接复位（如调度器状态异常）
警告断言：触发后记录日志，尝试降级运行（如某个传感器数据异常）
调试断言：仅在调试版本生效（如中间变量范围检查）

你想想看，如果生产环境完全关闭断言，一个内存越界写可能悄悄破坏数据，几周后才暴露。而保留安全断言，至少能在问题发生的第一时间留下线索。

避坑指南：我曾经在一个项目中，生产代码里保留了标准 assert。结果某个现场条件触发断言，系统直接 abort()，连日志都没来得及写。从那以后，我所有生产代码都用自定义断言，至少保证「死也要死得明白」。

总结一下

断言是防御式编程的重要工具，但要用对地方：

assert 检查「不可能发生」的内部逻辑错误
static_assert 在编译期检查结构体大小、常量范围等
错误处理应对「可能发生」的外部异常
生产环境不要完全移除断言，改用安全版本

记住一句话：断言是给开发者看的，错误处理是给用户看的。搞混了，代码就会变得既难调试又难维护。

好了，这一章就到这里。希望你在下一个项目里，能把断言用得恰到好处。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

断言的艺术：assert宏、静态断言与生产策略

一、assert 宏：运行时检查的利刃

二、静态断言 static_assert：编译期就发现问题

三、断言与错误处理：本质区别

四、生产环境下的断言策略

总结一下