第16章断言与错误处理

课程目录第16章断言与错误处理

16、断言与错误处理：assert的合理使用与生产环境移除

说到断言，我脑子里立刻浮现出刚入行时的一个场景。那时候我写了一个嵌入式通信协议栈，调试了整整三天，总觉得逻辑没问题。结果呢？一个同事看了一眼，淡淡说了句：「你这里加个 assert 试试。」好家伙，一加就崩，一查就找到了野指针。嗯，从那以后，我再也不敢小看 assert 了。

但话说回来，assert 这东西，用好了是神器，用不好就是给自己挖坑。今天咱们就好好聊聊，assert 到底该怎么用，生产环境又该怎么处理。

assert 的本质是什么？

说白了，assert 就是一个「调试期保镖」。它在 <assert.h> 里定义，本质上是个宏。你传给它一个表达式，如果表达式为假（0），它就调用 abort() 终止程序，同时打印出文件名、行号和失败条件。

#include <assert.h>

void set_speed(int speed) {
    assert(speed >= 0 && speed <= 100);
    // 正常处理逻辑
}

你看，这个 assert 就是在说：「speed 必须在 0 到 100 之间，否则就是 bug，别往下走了。」

assert 和 if 错误处理的区别

很多人会问：那我直接用 if 判断不行吗？当然行，但两者定位完全不同。

特性	assert	if 错误处理
用途	捕获程序内部逻辑错误（bug）	处理运行时可恢复的错误
生产环境	通常被移除（通过 NDEBUG）	保留，持续生效
行为	直接 abort，不可恢复	可返回错误码、重试、降级
典型场景	指针非空、数组索引不越界	文件打开失败、内存分配失败

我个人习惯这样区分：assert 检查的是「不可能发生」的事，if 检查的是「可能发生」的事。你想想看，如果函数参数传了个 NULL 进来，那是调用者的 bug，不是运行时环境的问题。这种就该用 assert。

assert 的合理使用场景

我在项目中遇到过不少滥用 assert 的情况。这里总结几个我认为比较合理的用法：

函数前置条件检查：比如参数不能为 NULL，索引必须在合法范围内。
函数后置条件检查：比如排序后确认数组有序，计算结果在预期范围内。
不可达分支检查：比如 switch-case 的 default 分支，理论上不该执行到。
数据结构不变量检查：比如链表操作后，检查头尾指针是否正确。

void insert_node(Node **head, int data) {
    assert(head != NULL);  // 前置条件：二级指针不能为空

    Node *new_node = (Node *)malloc(sizeof(Node));
    assert(new_node != NULL);  // 内存分配失败？那也是 bug 级别的

    new_node->data = data;
    new_node->next = *head;
    *head = new_node;

    assert(*head != NULL);  // 后置条件：插入后头节点不应为空
}

生产环境移除 assert

这是个大问题。assert 在调试阶段很有用，但到了生产环境，你肯定不希望因为一个 assert 触发就让整个系统崩溃。尤其是嵌入式设备，可能正在控制电机、处理医疗数据，突然 abort 了，后果不堪设想。

标准做法是：在编译时定义 NDEBUG 宏。一旦定义了 NDEBUG，所有 assert 宏都会被预处理器替换为空语句，不产生任何代码。

// 在编译命令中定义
gcc -DNDEBUG -o app main.c

// 或者在代码中定义（必须在包含 assert.h 之前）
#define NDEBUG
#include <assert.h>

但这里有个陷阱——assert 里的表达式如果有副作用，生产环境移除后副作用也会消失。我曾经见过这样的代码：

assert(++count < MAX_COUNT);  // 千万别这么写！

调试时 count 正常递增，生产环境一关 assert，count 再也不变了。你说坑不坑？所以我的原则是：assert 表达式里只做判断，不做操作。

警告：永远不要在 assert 表达式中写入赋值、自增、函数调用等有副作用的操作。生产环境移除 assert 后，这些副作用也会一并消失，导致程序行为不一致。

生产环境下的替代方案

那生产环境就不做检查了吗？当然不是。对于关键系统，我们可以自己实现一套「生产级断言」。

#ifdef PRODUCTION_ASSERT
    #define PROD_ASSERT(cond, msg) \
        do { \
            if (!(cond)) { \
                log_error("Assertion failed: %s, file %s, line %d", msg, __FILE__, __LINE__); \
                safe_recovery(); \
            } \
        } while(0)
#else
    #define PROD_ASSERT(cond, msg) ((void)0)
#endif

你看，这套方案有几个好处：

不直接 abort，而是记录日志并尝试恢复
可以携带更详细的错误信息
通过宏开关控制，调试和生产可以灵活切换

小技巧：在嵌入式系统中，我经常把 assert 失败时的信息通过串口或日志系统输出，同时点亮一个错误指示灯。这样既不会让系统死掉，又能快速定位问题。

知识体系结构图

下面这张图梳理了 assert 与错误处理的整体逻辑，你可以对照着回顾一下：

避坑指南

最后，我把自己踩过的坑整理一下，希望能帮你少走弯路：

不要在 assert 里写函数调用——我曾经在 assert 里调了一个状态更新函数，生产环境一关 assert，状态再也不更新了，排查了两天才发现。
不要用 assert 处理用户输入——用户输入错误是预期行为，应该用 if 处理并给出友好提示，而不是直接 abort。
不要依赖 assert 做安全检查——比如检查数组越界，生产环境 assert 被移除后，越界依然会发生。这种场景应该用静态分析工具或运行时边界检查。
团队统一 assert 使用规范——我建议在项目文档里明确：什么情况用 assert，什么情况用 if，避免每个人风格不同导致混乱。

核心总结：

assert 是调试工具，不是错误处理机制
生产环境通过 NDEBUG 移除 assert
assert 表达式不能有副作用
关键系统应实现自定义生产级断言

好了，关于 assert 和错误处理，今天就聊到这儿。记住一句话：assert 帮你发现 bug，但别让它成为生产环境的炸弹。下次写代码时，多想想这个 assert 该不该加，加了之后生产环境怎么办。嗯，养成这个习惯，你会感谢自己的。

📚 课程目录

16、断言与错误处理：assert的合理使用与生产环境移除

assert 的本质是什么？

assert 和 if 错误处理的区别

assert 的合理使用场景

生产环境移除 assert

生产环境下的替代方案

知识体系结构图

避坑指南