构造函数抛异常时对象未完全构造，析构函数不会调用；必须用RAII或两阶段初始化确保资源安全。noexcept声明不当会导致std::terminate，初始化列表中异常无法在函数体内捕获。
构造函数抛出异常后对象没被完全构造，析构函数不会调用
这是最常被忽略的前提：C++ 标准规定，如果 constructor 在执行中途抛出异常，对象的生命周期从未开始，因此对应的 destructor 绝对不会被调用。这意味着所有在构造函数中 new 出来的裸指针、手动 fopen 的文件句柄、pthread_mutex_init 的锁等，若没在异常前妥善清理，就会泄漏。
常见错误现象：std::bad_alloc 或自定义异常抛出后，程序内存持续增长、文件描述符耗尽、死锁。
- 用 RAII 容器替代裸资源管理（如用
std::unique_ptr替代new，用std::fstream替代fopen） - 把可能失败的操作尽量推迟到构造完成之后（例如拆成
init()成员函数，由用户显式调用） - 若必须在构造中分配资源，确保每一步都用栈上 RAII 对象兜底（比如先构造
std::vector，再用其data()做后续操作）
throw()、noexcept 和编译器优化的关系
noexcept 不是可选修饰——它是影响异常传播路径和性能的关键契约。如果构造函数声明为 noexcept 却抛出异常，程序会直接调用 std::terminate，不经过任何栈展开（stack unwinding），连已构造的成员变量的析构函数都不会运行。
使用场景：当你确定构造逻辑 100% 不会抛异常（比如只做 POD 赋值、移动语义、或内部全用 noexcept 函数），就该加 noexcept；否则不要加，尤其涉及 std::string、std::vector 构造、文件 I/O、网络调用时，默认就是可能抛异常。
立即学习“C++免费学习笔记（深入）”；
- 检查标准库容器构造是否可能抛异常：
std::vector<int>(n)</int>可能抛std::bad_alloc，不能随便标noexcept - 继承类构造函数的异常规范，必须与基类一致；基类构造抛异常，派生类构造也得能抛
- 模板类中，用
noexcept(expr)做条件 noexcept（如noexcept(std::is_nothrow_move_constructible_v<t>)</t>）
成员初始化列表里抛异常怎么捕获
初始化列表中的表达式（比如 member_(some_func())）一旦抛异常，根本进不了构造函数函数体，所以你在函数体内写的 try/catch 完全无效。
正确做法只有两个：一是在初始化表达式内部处理（比如让 some_func() 自己 catch 并转为返回错误码或默认值）；二是把初始化逻辑移到构造函数体内，改用赋值而非初始化列表（但要注意这可能导致默认构造 + 赋值两步开销，且对 const / 引用成员不可行）。
- const 成员、引用成员、无默认构造函数的类类型成员，必须在初始化列表中初始化，无法绕过 —— 这些地方若可能失败，只能提前验证输入，或封装成能保证成功的工厂函数
- 初始化列表顺序按成员声明顺序执行，不是书写顺序；靠后声明但先初始化的成员，若抛异常，前面已初始化的成员会自动析构（这是唯一能依赖的自动清理机制）
- 避免在初始化列表中调用可能抛异常的复杂函数；优先用简单表达式或已知安全的构造方式
想统一处理构造异常？别用 try/catch 包裹 new 表达式
很多人写 try { auto p = new MyClass(...); } 想捕获构造异常，但这样只是捕获了 new 分配失败（std::bad_alloc），真正的构造函数异常仍会向上抛。更糟的是，如果 MyClass 构造抛异常，new 已分配的内存会被自动释放（C++11 起），但你没机会干预这个过程。
真正可控的做法是：用 std::make_unique 或 std::make_shared 替代裸 new，它们内部已正确处理构造异常与内存释放的耦合；或者自己写工厂函数，在其中用 placement new + 显式析构做精细控制（仅限极少数需要定制释放逻辑的场景）。
-
std::make_unique<myclass>(args...)</myclass>抛异常时自动释放内存，且返回std::unique_ptr，安全又简洁 - 不要重载全局
operator new来“拦截”构造异常 —— 它只管分配，不管构造 - 如果使用自定义分配器，确保其
construct()方法遵循异常安全规则：抛异常时不对已构造对象做任何假设
构造函数异常的本质，是告诉调用方“这个对象我造不出来”，而不是“我造了一半卡住了”。所有试图在构造中做复杂错误恢复的思路，往往比改成两阶段初始化（构造 + init）更难维护、更容易漏掉清理点。
