3. 断言机制：静态断言、动态断言、断言触发后的处理策略

说到断言，很多刚入行的朋友觉得它就是「检查一下条件对不对」。嗯，这话没错，但太浅了。我在HAL层摸爬滚打这些年，断言机制其实是我最依赖的「守门员」。它能在错误发生的第一时间把你叫醒，而不是等到系统崩溃了才追悔莫及。

今天咱们就聊聊三种断言：静态断言、动态断言，以及断言触发后该怎么办。我个人习惯把断言看作是代码里的「安全气囊」——平时不触发最好，一旦触发，说明真的出事了。

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

静态断言，说白了就是在编译阶段做检查。你想想看，有些错误如果能提前到编译期发现，那可比运行时排查省心多了。

在C语言里，我们常用 _Static_assert（C11标准引入）。在C++里则是 static_assert。它的核心作用就是验证编译期常量表达式。

我在项目中遇到过这样一个场景：某个HAL层的结构体需要严格对齐到4字节，但不同编译器下结构体填充规则不一样。如果对齐不对，DMA传输就会出问题。用静态断言就能在编译时卡住这个问题。

// 静态断言示例：检查结构体大小是否符合预期
#include <assert.h>

typedef struct {
    uint32_t reg1;
    uint16_t reg2;
    uint8_t  reg3;
    uint8_t  reserved;
} __attribute__((packed)) DeviceConfig;

// 静态断言：确保结构体大小为8字节
_Static_assert(sizeof(DeviceConfig) == 8, 
               "DeviceConfig 结构体大小异常，请检查对齐方式");

// 另一个常见用法：检查枚举值范围
_Static_assert(MAX_CHANNEL_COUNT <= 16, 
               "通道数不能超过16个，硬件不支持");

3.2 动态断言：运行时的哨兵

动态断言是在程序运行时检查条件。如果条件为假，就会触发断言失败。标准C库提供了 assert() 宏，但说实话，在嵌入式环境里，我很少直接用标准库的断言——因为它太「粗暴」了，直接调用 abort() 结束程序。

在HAL层开发中，我更推荐自定义断言宏。为什么呢？因为嵌入式系统往往需要更精细的控制——比如记录错误现场、触发看门狗复位、或者尝试恢复。

// 自定义动态断言宏（HAL层专用版）
#include <stdio.h>
#include <stdlib.h>

#define HAL_ASSERT(cond, msg) do { \
    if (!(cond)) { \
        hal_error_handler(__FILE__, __LINE__, __func__, msg); \
    } \
} while(0)

// 错误处理函数
void hal_error_handler(const char *file, int line, 
                       const char *func, const char *msg) {
    // 记录错误信息到日志缓冲区
    log_error("断言失败: %s:%d [%s] - %s", file, line, func, msg);
    
    // 保存CPU寄存器现场（用于后续分析）
    save_crash_context();
    
    // 触发系统复位或进入安全模式
    system_reset();
}

3.3 断言触发后的处理策略

断言触发了，然后呢？很多人的第一反应是「程序崩了，重启吧」。但作为一个负责任的HAL层开发者，我们需要更优雅的处理方式。

我总结了一套「三级处理策略」，你可以根据断言的重要程度来选择：

级别	触发条件	处理方式	适用场景
L1 致命	硬件状态异常、内存损坏	立即复位，保存现场	DMA传输错误、关键寄存器配置失败
L2 严重	参数校验失败、状态机异常	记录日志，尝试恢复	外设初始化失败、中断嵌套异常
L3 警告	非关键条件不满足	仅记录，继续运行	超时重试、缓存命中率低

来看看具体实现：

// 三级断言处理实现
typedef enum {
    ASSERT_LEVEL_FATAL = 0,
    ASSERT_LEVEL_ERROR = 1,
    ASSERT_LEVEL_WARN  = 2
} assert_level_t;

#define HAL_ASSERT_LEVEL(cond, level, msg) do { \
    if (!(cond)) { \
        hal_assert_handler(level, __FILE__, __LINE__, __func__, msg); \
    } \
} while(0)

void hal_assert_handler(assert_level_t level, const char *file, 
                        int line, const char *func, const char *msg) {
    switch(level) {
        case ASSERT_LEVEL_FATAL:
            // 致命错误：保存现场，立即复位
            save_full_context();
            log_fatal("致命断言失败: %s:%d [%s] - %s", 
                      file, line, func, msg);
            NVIC_SystemReset();
            break;
            
        case ASSERT_LEVEL_ERROR:
            // 严重错误：尝试恢复
            log_error("严重断言失败: %s:%d [%s] - %s", 
                      file, line, func, msg);
            if (try_recovery() == false) {
                // 恢复失败，升级为致命错误
                hal_assert_handler(ASSERT_LEVEL_FATAL, file, line, func, 
                                   "恢复失败，升级处理");
            }
            break;
            
        case ASSERT_LEVEL_WARN:
            // 警告：仅记录
            log_warn("断言警告: %s:%d [%s] - %s", 
                     file, line, func, msg);
            break;
    }
}

3.4 断言机制的核心逻辑图

下面这张图展示了断言机制在HAL层中的完整工作流程。你可以看到，从编译期到运行期，断言是如何层层把关的。

3.5 实战中的几个要点

说了这么多，最后分享几个我在实际项目中总结的经验：

• 断言不是日志：很多人把断言当printf用，这是不对的。断言只检查「不应该发生」的情况，而不是「可能发生」的情况。正常的错误处理应该用if-else。
• 断言要可追溯：每个断言触发时，一定要记录足够的信息——文件名、行号、函数名、错误描述。否则你拿到一个「断言失败」的日志，根本不知道哪里出了问题。
• 不要滥用断言：我见过有人每个函数入口都加十几个断言检查参数。这反而降低了代码的可读性。我的原则是：只检查那些「如果出错会导致灾难性后果」的条件。
• Release版本的处理：即使发布版本，我也建议保留L1级别的断言。因为L1级别的错误往往意味着硬件故障或严重逻辑错误，这时候「继续运行」比「崩溃」更危险。

可可精品资料库