assert 压根儿就不是用来处理错误的——它只在调试阶段生效，一旦你定义了 NDEBUG，它就直接消失。不是变弱了，是编译器根本不会生成它的调用代码。
为什么 Release 模式下 assert 完全不工作
原因很简单，assert 是个宏，不是函数。它的展开逻辑完全由预处理器决定：只要在 #include 之前定义了 NDEBUG，assert(expression) 就会被替换成一个空语句——static_cast，不产生任何机器码。
但要注意顺序：
- 错误写法：
#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，是设计使然。真要保清理，得自己写检查加异常处理。
