noexcept构造函数中throw会直接调用std::terminate终止程序，不执行栈展开、不调用任何析构函数，资源泄漏风险真实存在；这是运行时契约违约，非编译期错误。
noexcept构造函数里throw会直接终止程序
声明为 noexcept 的构造函数如果实际抛出了异常，C++ 标准规定：不进入栈展开，不调用任何析构函数，而是立即调用 std::terminate() 终止整个进程。这不是“报错后继续执行”，而是硬性中止 —— 和访问空指针崩溃的后果类似，但更静默（无堆栈信息，除非你装了 terminate handler）。
- 它不会像普通
throw那样被外层catch捕获 - 即使该构造函数是某个
try块内唯一语句，也不会触发匹配的catch - 所有已构造的局部对象（包括 this 对象的基类、成员）的析构函数都不会运行 —— 资源泄漏风险真实存在
为什么编译器不阻止你在noexcept里写throw
因为 noexcept 是契约，不是编译期强制检查。编译器只做静态分析：若你能写出 throw，它就默认你“知道自己在干什么”；真正校验发生在运行时（即抛出那一刻）。这也是常见误用源头 —— 开发者以为加了 noexcept 就安全，结果在移动构造里调用了可能 throw 的成员函数（比如 std::vector::push_back 申请内存失败抛 std::bad_alloc），而没意识到这违反了契约。
-
noexcept函数体内仍可写throw，只要不被执行到，编译就通过 - 编译器对
noexcept的验证仅限于“是否显式抛出已知异常”，无法覆盖所有动态行为（如new失败、dynamic_cast引用失败等） - 真正可靠的判断方式是：用
noexcept(表达式)运算符在模板中做编译期断言，例如static_assert(noexcept(T(std::move(x))), "T must be nothrow move constructible");
移动构造函数标noexcept却抛异常的连锁反应
这是最常踩坑的场景。标准库容器（如 std::vector）在扩容时，会优先尝试移动元素；但如果元素类型的移动构造函数不是 noexcept，容器会退回到拷贝构造 —— 因为它必须保证强异常安全：万一移动中途抛异常，已有部分元素已被移动走，状态无法回滚。所以你写了移动构造却没标 noexcept，或标了却偷偷抛了异常，结果就是性能掉一截，还可能掩盖真正的资源管理问题。
-
std::vector::resize、reserve、push_back（触发重分配时）都会依赖is_nothrow_move_constructible_v<t></t> - 若你手动实现移动构造并调用了非
noexcept的函数（比如未检查的new、at()、dynamic_cast&），就算加了noexcept修饰，也属于契约违约 - 调试时注意：GDB/LLDB 在
std::terminate被调用前通常不中断，需提前设断点在throw语句或启用catch throw
怎么确认你的noexcept构造函数真不会抛异常
不能靠“我没写 throw 就行”，得看它调用的所有函数是否都满足 noexcept。最稳妥的方式是组合使用 noexcept 运算符 + 类型特征 + 静态断言，把检查推到编译期。
立即学习“C++免费学习笔记（深入）”；
- 检查成员初始化：若成员类型
M的移动构造不是noexcept，那T(T&&)就不该标noexcept - 避免在
noexcept构造函数里调用标准库可能抛异常的接口，例如：std::vector::at()、std::string::substr()（越界）、std::stoi()（格式错误） - 用
noexcept(表达式)做条件判断：例如Resource(Resource&& other) noexcept(noexcept(data = other.data))，虽然赋值本身不抛，但能帮你发现隐含风险 - 实际项目中建议配合 sanitizer：Clang/GCC 的
-fsanitize=undefined可捕获部分noexcept违约行为（依赖运行时检测）
真正难的不是加 noexcept，而是确保它所依赖的每一条执行路径都不抛 —— 这要求你对每个被调用函数的异常规范有明确认知，而不是凭印象或文档片段做判断。
