assert.h 看起来只是一个很小的头文件，但它在 C 开发里的作用并不小：把“这里本来就应该成立”的条件直接写进代码，在问题刚出现时就停下来。下面从断言的工作方式、基础写法、编译开关、适用场景和常见误区几部分展开，帮助你判断它该放在哪里、又不该拿来做什么。
什么是 assert，失败时会发生什么
断言是一种面向调试的条件检查机制。程序运行到断言语句时，会先计算表达式的值：
- 如果结果为真，也就是非
0，程序继续执行； - 如果结果为假，也就是
0，程序会立刻终止，并输出错误信息。
它的核心用途是验证程序员自己的假设，例如“这个指针此时不该为空”“这个索引一定在范围内”“进入这个分支前状态必须已经初始化”。因此，断言主要用于发现逻辑错误，而不是处理运行时异常，更不是面向用户的报错手段。
断言能解决什么问题
- 快速定位错误：条件一旦不成立，程序会在出问题的现场停下，便于回溯原因。
- 简化调试：把代码里的前提条件直接写出来，比靠注释或脑补更可靠。
- 保持代码清晰：相比到处手写临时检查逻辑，断言通常更简洁。
它的边界也很明确
- 会带来额外开销：启用断言时，每次执行都需要检查表达式。
- 不适合处理外部错误：比如用户输入非法、文件不存在、网络失败，这些都不该只靠断言处理。
如何使用 assert
使用断言需要包含 assert(...) 中。
// www.ja vascriptcn.com code example #include#include int main() { int x = 5; assert(x > 0); // 如果x不大于0，程序将终止并输出错误信息 printf("x is positive: %dn", x); return 0; }
这段程序里，assert(x > 0) 表示“x 在这里必须大于 0”。如果条件成立，程序会继续打印结果；如果不成立，程序就在这一行终止。
需要注意的是，断言适合放在关键假设点，而不是拿来包办所有分支判断。它强调的是“这里本来就不该错”，而不是“这里可能出错，所以我要正常处理”。
编译时如何启用或禁用断言
在多数编译环境下，断言默认是启用的。以 GCC 为例，正常编译可以直接使用：
gcc -o program_name program.c
如果你希望在编译时禁用断言，可以定义宏 NDEBUG：
gcc -DNDEBUG -o program_name program.c
定义 NDEBUG 后，源码中的 assert(...) 会被禁用。这也是为什么断言通常更适合开发和调试阶段：它可以帮助尽早暴露程序内部假设错误，而在发布版本中则常被关闭，以减少不必要的检查开销。
这里还有一个实践判断标准：如果某个检查在发布版本里也必须执行，那它就不应只写成断言，而应该保留正式的错误处理逻辑。
哪些场景适合使用断言
断言最适合验证“程序内部本应成立的条件”，常见场景主要有以下几类。
边界条件检查
例如进行数组操作前，先确认索引位于有效范围内。这类检查可以帮助你尽早发现越界访问背后的逻辑问题。
函数参数验证
如果某个内部函数只接受满足特定条件的参数，例如必须是正数、必须非空、必须已经初始化，那么断言可以把这些约束直接固定在函数入口处。
状态一致性验证
当程序在不同状态之间切换时，可以使用断言确认当前状态满足预期。例如某个模块在执行某操作前，必须已经完成初始化；如果没有，就说明调用时机有问题。
断言不能替代什么
断言常见的误用，是把它当成统一错误处理手段。这个用法并不合适。
- 不能代替外部错误处理：文件不存在、资源不可用、用户输入非法，这些都属于现实运行环境中的正常失败路径，应该使用错误码、返回值或其他正式机制处理。
- 不能代替业务校验：如果某个条件失败后，程序需要给用户反馈、记录日志、尝试恢复，断言就不适合承担这个职责。
- 不能依赖它保证线上安全：因为一旦使用
-DNDEBUG编译，这些断言检查本身就可能被移除。
换句话说，断言更像是写给开发者自己的“内部约束”，而不是写给最终用户的“错误提示系统”。
使用建议与练习
assert.h 提供了一种简洁直接的方式，用来在开发过程中捕获潜在编程错误。用得好，它能明显提升代码可读性、调试效率和维护质量；用得不当，则容易和正式错误处理混淆。
可以用下面几道练习来加深理解：
- 编写一个程序，使用断言来确保用户输入的年龄大于0。
- 修改上述程序，使其在生产环境中禁用断言。
- 设计一个函数，该函数接受两个整数参数，并返回它们的和。使用断言来确保传入的参数都是正数。
做完这几步后，你通常就能比较清楚地区分：哪些条件适合写成断言，哪些则必须进入真正的错误处理流程。
