assert仅在NDEBUG未定义时生效，Debug模式下触发abort并输出信息，Release模式下被预处理器完全移除；其参数须为无副作用的纯表达式，不可用于运行时错误处理，失败时进程终止且不执行析构函数。
assert 在调试模式下才起作用
assert 是 C++ 标准库（NDEBUG 宏未定义时生效**。也就是说，它默认只在 Debug 构建中触发检查，Release 构建中整条 assert 语句会被预处理器直接移除，不生成任何代码、不消耗运行时开销。
常见错误现象：你在 Release 模式下写了 assert(ptr != nullptr)，但程序崩溃了——这不是 assert 没“起作用”，而是它根本没编译进去，后续解引用空指针才真正崩的。
- Debug 模式：通常不定义
NDEBUG，assert有效，失败时调用abort()并打印文件名、行号和表达式 - Release 模式：编译器（如 MSVC、GCC、Clang）默认定义
NDEBUG，assert展开为空操作 - 手动控制：可在代码顶部加
#define NDEBUG提前禁用；或编译时传-DNDEBUG（GCC/Clang）或/DNDEBUG（MSVC）
assert 的参数必须是无副作用的纯表达式
assert 接收一个 bool 表达式，但它本质是宏，不是函数。一旦被移除（Release 下），其内部所有计算、函数调用、变量修改都会消失——这会导致逻辑错乱。
典型错误写法：assert(x++ > 0) 或 assert(foo() == true)。前者在 Release 下 x 不会自增；后者在 Release 下 foo() 根本不执行，可能跳过关键副作用（比如日志、状态更新、资源申请）。
立即学习“C++免费学习笔记（深入）”；
- 正确做法：把有副作用的操作拆到
assert外面，只在括号里放纯判断，例如：int result = compute();
assert(result >= 0); - 如果必须验证带副作用的逻辑，改用显式
if+ 错误处理（如抛异常、返回错误码），而不是依赖assert - 注意：
assert不适用于检查用户输入、文件读取失败、内存分配失败等运行时不可控条件——它只适合捕获程序员的逻辑错误（比如“此处i绝对不能为负”）
assert 失败时输出信息有限，不支持自定义消息
标准 assert 只打印表达式文本、文件名和行号，比如：Assertion `ptr != nullptr' failed.。它不支持像 assert(ptr != nullptr && "pointer must be valid"); 这样的字符串附加（C++20 前无效，该写法会编译失败）。
如果你需要更清晰的上下文，有两个轻量方案：
- 用逻辑与拼接描述性子表达式：
assert(ptr != nullptr && "ptr should be initialized before use")—— 注意：这依赖于短路求值，&&右侧字符串字面量恒真，不会影响判断，但会被编译器保留为表达式一部分，部分实现（如 GCC）能在失败时显示整行内容 - 更可靠的方式：自己封装一个简易宏，例如：
#define MY_ASSERT(cond, msg) do { \
if (!(cond)) { \
fprintf(stderr, "ASSERTION FAILED: %s (%s:%d)\n", msg, __FILE__, __LINE__); \
abort(); \
} \
} while(0) - 不要试图重定义
assert——它被标准严格规定，自定义行为可能破坏跨平台兼容性
调试模式下 assert 崩溃后无法继续执行
assert 失败会调用 std::abort()，进程立即终止，不执行栈展开（RAII 析构函数不运行），也不抛异常。这意味着你没法在崩溃后 inspect 变量、单步回溯，除非借助调试器中断机制。
VS 和 GDB 都支持在 abort 调用前中断：VS 中启用“Windows 异常”里的 raise 或 abort；GDB 中用 catch signal SIGABRT。但这属于调试器技巧，不是 assert 本身的能力。
- 如果希望断言失败后仍可控（比如记录日志、弹窗、进入调试器），应避免直接用
assert，改用条件 +__debugbreak()（MSVC）或__builtin_trap()（GCC/Clang） - 在单元测试或脚本化构建中，
assert崩溃会导致整个测试进程退出，难以定位多个失败点——这时更适合用测试框架的EXPECT_TRUE等可恢复断言 - 多线程环境下，
assert失败发生在哪个线程就崩哪个线程，但主线程未必是触发者，需结合线程 ID 和调用栈确认上下文
