assert在Release模式下被预处理器整行剔除，因NDEBUG宏默认启用；它仅用于调试，不可含副作用，非运行时校验手段。
assert 在 Release 模式下直接消失，不是“没生效”而是被编译器删了
这是最常让人懵圈的一点：代码里写了 assert(ptr != nullptr)，Debug 下报错停住，一跑 Release 就像没写过——不是 bug，是标准行为。C++ 的 assert 本质是宏，定义在 NDEBUG：只要定义了它（MSVC / GCC 默认在 Release 配置中定义），所有 assert 行都会被预处理器整行剔除，不占空间、不耗时间、也不检查。
所以别指望它在生产环境兜底。真要运行时校验，得用自定义断言或 if + std::terminate。
- 调试阶段放心用，但别把它当逻辑分支来写副作用，比如
assert(x++ > 0)—— Release 下x根本不加 - 跨平台项目注意：某些嵌入式工具链可能默认定义
NDEBUG，即使在 Debug 构建中 - 想临时禁用所有 assert？加编译选项
-DNDEBUG；想强制启用？确保构建时不定义它，或手动#undef NDEBUG（不推荐）
assert 参数必须是纯表达式，不能带 std::cout 或 throw
assert 接收一个 C 风格的“可求值表达式”，求值结果转为 bool。一旦表达式里出现副作用操作（尤其是流输出、函数调用、异常抛出），Debug 和 Release 行为会彻底割裂：
-
assert(ptr && "ptr is null");✅ 合法：字符串字面量只是地址，无副作用 assert(ptr || (std::cout ❌ 危险：Release 下整个右边被删，std::cout不执行；Debug 下虽能打印，但违反 assert 本意（它只该用于诊断，不该负责日志）-
assert(func());❌ 隐患：如果func()有状态变更（如修改全局变量、分配资源），Release 下这行消失，逻辑就变了
真正需要日志+断言的场景，用 if (!cond) { log(); std::terminate(); } 更可控。
立即学习“C++免费学习笔记（深入）”；
替代方案：用 static_assert 做编译期检查，和 assert 互补
assert 查运行时，static_assert 查编译期，两者不重叠、不替代。比如检查模板参数约束、对齐要求、枚举值范围：
templatevoid process(T* p) { static_assert(std::is_trivially_copyable_v , "T must be trivially copyable"); assert(p != nullptr); }
-
static_assert错误在编译时报出，无法绕过；assert错误在运行时报出，可被跳过 - 不能用
static_assert检查变量值（如static_assert(x > 0)❌），因为x不是常量表达式 - 从 C++17 起支持
static_assert(msg)形式，消息必须是字符串字面量，不能拼接
第三方断言库（如 gsl::fail_fast）比原生 assert 更适合现代 C++ 工程
原生 assert 打印信息极其简陋（只有文件/行号/条件），且终止方式不可控（调用 abort()，不走栈展开）。大型项目常用更健壮的替代：
-
GSL的Expects/Ensures：带语义、可配置失败行为（记录、回调、抛异常） -
Boost.Stacktrace配合自定义断言：崩溃时自动打印调用栈，不用等 debugger - 自己封装一层：比如
MY_ASSERT(cond, "msg")宏，在 Debug 下调用assert，在 Release 下转为log_and_terminate，保持行为一致性
关键不是换不换，而是意识到：assert 是调试探针，不是错误处理机制。一旦你开始纠结“怎么让 assert 在 Release 下也起作用”，说明它已经越界了。
真正容易被忽略的是：很多团队把 assert 当作“快速测试”，结果在 CI 流水线里跑 Release 构建，断言全失效，问题漏到线上才暴露。盯紧你的构建配置，比多写十个 assert 都管用。
