📚 课程目录第4章断言assert

4. 断言assert

说到C语言的错误处理，有个工具我特别喜欢——assert宏。说白了，它就是你在代码里埋下的「哨兵」。程序跑着跑着，一旦条件不满足，立马炸给你看。

我个人习惯在开发阶段大量使用assert。为什么呢？因为它能帮我尽早发现问题。你想想看，一个bug在编译阶段被发现，和在线上运行三个月后才暴露，修复成本完全不是一个量级。

4.1 assert宏的基本用法

assert定义在<assert.h>里。用法极其简单：

#include <assert.h>

int divide(int a, int b) {
    assert(b != 0);  // 除数不能为0
    return a / b;
}

int main() {
    int result = divide(10, 0);  // 这里会触发assert
    return 0;
}

运行这段代码，如果b等于0，程序会直接终止，并打印出类似这样的信息：

Assertion failed: b != 0, file test.c, line 4

看到没？文件名、行号、失败条件，一目了然。我在项目中遇到过好几次，同事写的代码里指针传进来是NULL，debug了半天才发现。后来我建议他在函数入口加个assert，问题当场暴露。

核心要点：assert只在调试阶段生效。它不是一个运行时错误处理机制，而是开发期的「自检工具」。

4.2 assert与NDEBUG

这里有个关键点：assert的生效与否，取决于一个宏——NDEBUG。

如果定义了NDEBUG，assert就变成空操作，啥也不干。通常我们在发布版本里会定义它：

// 调试版本：assert生效
gcc -o test test.c

// 发布版本：assert被移除
gcc -DNDEBUG -o test test.c

为什么会这样设计？嗯，这里要注意：assert的目的是帮你抓bug，不是处理运行时错误。一旦产品上线，你希望程序能优雅地处理异常，而不是直接崩溃。

编译模式	NDEBUG状态	assert行为
Debug	未定义	检查条件，失败则终止
Release	已定义	完全忽略，无性能开销

我的建议：在Makefile或构建脚本里，明确区分debug和release的编译选项。我曾经见过一个项目，发布版本忘了加-DNDEBUG，结果线上程序因为一个assert直接挂了——那场面，相当尴尬。

4.3 assert的优缺点

任何工具都有两面性，assert也不例外。

优点

零开销检查：发布版本里assert被完全移除，不影响性能
信息丰富：失败时自动打印文件名、行号、条件表达式
简单直接：一行代码就能做防御性检查
文档化：assert本身就是一种「可执行的注释」，告诉读者这里有什么前置条件

缺点

副作用风险：assert里的表达式会被完全求值。如果表达式有副作用，debug和release版本行为会不一致
无法自定义：失败时的行为是固定的——直接abort。你不能改成打印日志后继续运行
容易被滥用：有些人把assert当成错误处理来用，这是不对的

避坑指南：千万不要在assert里写带副作用的表达式！

// 错误示范
assert(++count < 100);  // debug版本会自增，release版本不会

// 正确做法
++count;
assert(count < 100);

我曾经在一个网络库的代码里看到有人这么写，debug版本跑得好好的，release版本逻辑全乱了。查了两天才找到原因——就是assert里的副作用在搞鬼。

4.4 生产环境中的断言策略

到了生产环境，assert该怎么用？我的经验是：

区分「应该发生」和「可能发生」
- assert用于「理论上绝对不应该发生」的情况
- if-else用于「可能发生、需要处理」的情况
保留关键断言
- 有些断言涉及安全或数据完整性，即使上线也不能丢
- 这时候就别用assert了，自己写一个「永不关闭的断言」
日志替代方案
- 生产环境里，我更倾向于用日志记录异常，而不是直接崩溃
- 比如：检测到非法参数，记录错误日志，然后返回错误码

// 生产环境友好的做法
#define ASSERT_ALWAYS(cond, msg) \
    do { \
        if (!(cond)) { \
            fprintf(stderr, "FATAL: %s at %s:%d\n", msg, __FILE__, __LINE__); \
            abort(); \
        } \
    } while(0)

// 使用示例
void process_data(void* ptr) {
    ASSERT_ALWAYS(ptr != NULL, "ptr must not be NULL");
    // 处理数据...
}

总结一下我的策略：

开发阶段：大量使用assert，把bug扼杀在摇篮里
测试阶段：保留assert，配合测试用例验证逻辑
生产阶段：移除标准assert，用自定义的「永不关闭断言」处理关键检查

说白了，assert就是个「调试期的保镖」。它帮你守住代码的底线，但你不能指望它处理所有问题。真正健壮的程序，靠的是完善的错误处理体系，而不是几个assert。