assert 在运行时怎么用，什么情况下会崩
断言不是日志，也不是错误处理；它只在调试时帮你快速发现“本不该发生”的逻辑错。一旦 assert 条件为假，程序直接调用 abort() 终止——不抛异常、不清理栈、不执行析构函数。
常见错误现象：assert(ptr != nullptr) 写在函数开头，但发布版（NDEBUG 定义后）整个语句被编译器剔除，导致空指针一路跑到后续操作才崩，反而更难定位。
- 只对内部不变量、前置/后置条件、算法中间状态做断言，比如
assert(i >= 0 && i 检查下标，而不是代替边界检查 - 别在断言里写有副作用的表达式：
assert(x++ > 0)—— 发布版里x就不会自增，行为不一致 - 字符串字面量可选，但别依赖它做用户提示：
assert(ptr && "ptr must be valid")，因为有些旧编译器不支持带消息的assert - 头文件要显式包含
<cassert></cassert>，C++ 中不靠<assert.h></assert.h>
static_assert 编译期断言必须写在哪、能查什么
static_assert 是真正的编译期守门员，条件不满足直接报错，连目标文件都不会生成。但它不能访问运行时值，只能查类型、常量表达式、模板参数约束等。
常见错误现象：写 static_assert(std::is_same_v<t int>, "...")</t> 却忘了加 template<typename t></typename>，结果编译器报错说 T 未声明；或者拿 sizeof(x) 去断言变量大小，却误用了运行时变量 x 而非类型 sizeof(T)。
立即学习“C++免费学习笔记（深入）”；
- 位置很自由：命名空间级、类定义内、函数体内（C++17 起）、模板特化前都行，但不能在函数参数默认值或 return 语句里
- 第二个参数（错误信息）必须是字符串字面量，不能是
std::string或变量 - 检查模板约束最实用：比如要求传入类型支持
operator+，就用static_assert(std::is_arithmetic_v<t>)</t> - C++20 后支持
static_assert带constexpr函数调用，但函数本身必须满足常量求值要求
assert 和 static_assert 混用时容易漏掉的兼容点
两者根本不在一个时间维度上工作，混用时最容易踩的是“以为写了 static_assert 就不用 assert”或者“以为 assert 能替代类型检查”。它们解决的问题域几乎不重叠。
使用场景差异明显：比如写一个泛型容器，static_assert 可确保模板参数是可复制的（std::is_copy_constructible_v<t></t>），而 assert 则用于运行时检查 size() 这种动态不变量。
-
assert依赖NDEBUG宏，而static_assert完全不受影响——发布版照样报错 - 某些嵌入式或裸机环境禁用
abort()，此时assert可能被重定义为空宏，但static_assert仍生效 - 模板推导失败时，
static_assert的错误信息比 SFINAE +enable_if清晰得多，但别指望它能捕获运行时数据非法（比如除零） - 跨平台项目中，MSVC 对
static_assert消息长度有限制（约 1024 字符），GCC/Clang 更宽松
什么时候该用 assert，什么时候该用异常或返回错误码
断言不是错误处理机制。它只回答一个问题：“如果这都不成立，说明我代码写错了，别跑了，赶紧修。”
常见错误现象：把用户输入校验写成 assert(!input.empty())，结果一遇到空字符串就崩溃；或者在网络请求失败时用 assert(status == 200)，把外部不确定性当成了内部 bug。
- 用
assert：检查函数内部假设（如私有成员变量始终非负）、算法中间状态（如排序过程中某段已有序）、调试专用 invariant - 用异常或错误码：处理外部输入、I/O 失败、资源不足、协议错误等预期可能发生的失败
- 别在析构函数里用
assert——万一它真触发了，会调用std::terminate()，而析构函数本就不该抛异常 - 多线程环境下慎用
assert检查共享状态，除非你明确加了锁且确认断言条件在临界区内稳定
