C++ assert断言调试 _ 运行时检查与NDEBUG宏控制【详解】

assert 压根儿就不是用来处理错误的——它只在调试阶段生效，一旦你定义了 NDEBUG，它就直接消失。不是变弱了，是编译器根本不会生成它的调用代码。

为什么 Release 模式下 assert 完全不工作

原因很简单，assert 是个宏，不是函数。它的展开逻辑完全由预处理器决定：只要在 #include 之前定义了 NDEBUG，assert(expression) 就会被替换成一个空语句——static_cast(0)，不产生任何机器码。

但要注意顺序：

• 错误写法：#include #define NDEBUG —— 顺序反了，assert 已经被展开，NDEBUG 完全无效
• 正确写法：在 CMake 里加 add_definitions(-DNDEBUG)，或者在源文件最顶部写 #define NDEBUG 再 #include
• 验证方法：在 assert(false) 后面加一行 std::cout << "alive\n"，Debug 版本不会输出，Release 版本会输出

assert 表达式里写函数调用的坑

其实最隐蔽也最危险的误用，是在 assert 的表达式里塞了有副作用的操作——比如修改变量、释放资源、打印日志。这会直接导致 Debug 和 Release 的行为分裂。

• assert(free(ptr))：Debug 下 free 正常执行，Release 下直接跳过，ptr 泄漏
• assert(x++ > 0)：Debug 下 x 自增，Release 下不变，后续逻辑全乱
• assert(validate_and_log(data))：Debug 下打日志，Release 下静默，监控彻底丢失
• 安全做法很简单：把有副作用的操作拆出来单独写，validate_and_log(data); assert(data.is_valid());

什么时候该用 assert，什么时候必须用 if + 错误分支

判断标准只有一个：这个条件，在程序逻辑上是不是“绝对不该为假”。如果是外部输入、系统调用失败、文件不存在、网络超时——这些全是合法的运行态，assert 不能碰。

• 适合 assert 的场景：assert(ptr != nullptr)（内部指针理论上不该为空）、assert(i < vec.size())（索引由你控制，越界说明算法写错了）
• 必须用 if 的场景：if (fopen("config.txt", "r") == nullptr)（文件可能真被用户删了）、if (recv(sock, buf, len, 0) < 0)（网络抖动是常态）
• 浮点数比较是个陷阱：assert(a == b) 几乎总是错的，改用 assert(std::abs(a - b) < 1e-6)

自定义断言信息怎么写才真正有用

光写 assert(x > 0) 只能知道“x 不大于 0”，但不知道 x 具体是多少、上下文是什么。加一段字符串字面量是 GCC/Clang 支持的扩展，能显著缩短定位时间。

• 基础写法：assert(x > 0 && "x must be positive");，失败时 stderr 会输出这段字符串
• 带值调试：assert((x > 0 && "x must be positive") || (fprintf(stderr, "x=%d\n", x), false)); —— 仅限 Debug，慎用
• 更稳妥的替代方案：if (x <= 0) { std::cerr << "x=" << x << " violates precondition\n"; std::abort(); }

还有一点很容易被忽略——assert 触发后直接调用 std::abort()，不做栈展开，不析构局部对象，不执行 atexit 注册的函数。如果类里有文件句柄、锁、临时文件，assert 崩溃可能导致资源卡死或数据损坏。这不是 bug，是设计使然。真要保清理，得自己写检查加异常处理。