assert()是契约检查工具而非调试开关，Release下因NDEBUG被移除，不可用于运行时校验或错误处理；应改用static_assert、自定义宏或显式错误分支。
断言在 C++ 里不是调试“开关”，而是契约检查工具——用错地方反而掩盖问题，甚至让 Release 版本崩溃。
assert() 在 Release 下直接消失，别指望它做运行时校验
标准 assert() 依赖 NDEBUG 宏：编译时定义了它，所有 assert() 调用会被预处理器彻底删掉。这意味着：
- Release 构建中，
assert(ptr != nullptr)不会执行，也不会报错，哪怕ptr真是空指针 - 不要在
assert()里放有副作用的表达式，比如assert(x++ > 0)—— Debug 可能通过，Release 却跳过自增，逻辑错乱 - 它只适合检查“绝不该发生”的内部假设，比如算法中间状态、私有函数入参约束
替代方案：static_assert 和自定义断言宏
编译期断言用 static_assert，运行期需要保留的断言得自己封装：
-
static_assert检查编译期常量，例如static_assert(sizeof(int) == 4, "int must be 4 bytes") - 想让 Release 也触发检查？定义自己的宏，比如
MY_ASSERT，底层调用std::abort()或日志+抛异常，不依赖NDEBUG - 注意：自定义断言若含
throw，需确保调用栈能被正确捕获；若用abort()，不会有栈展开，资源可能泄漏
常见误用：在 public 接口或用户输入路径里用 assert()
断言不是错误处理机制。下面这些写法很危险：
立即学习“C++免费学习笔记（深入）”；
-
assert(argv[1] != nullptr)—— 命令行参数缺失是正常场景，该用 if 判断 + 友好提示 -
assert(std::cin >> value)—— 输入失败是常态，assert()会让程序在用户输错时直接 abort - 在 DLL 导出函数、回调函数、多线程临界区里用
assert()，可能因环境不可控导致崩溃难以定位
调试时 assert 失败没反应？检查编译器和标准库行为
有些环境下 assert() 失败不弹窗、不打印，默认静默 abort：
- Windows 控制台程序：确保链接了 C 运行时（如 /MD），否则
assert()可能无输出 - Linux：检查是否重定向了
stderr，失败信息默认写到stderr - 某些嵌入式或裁剪版 STL（如 libc++ 的 minimal mode）可能禁用
assert()输出，只 abort - 用
gdb调试时，可设断点：catch throw或break __assert_fail（GNU libc）
真正难的不是加断言，而是判断哪条逻辑“绝不可能为假”——一旦你开始犹豫，就该换成显式错误分支或日志记录。
