析构函数是C++中唯一能保证对象销毁时自动执行清理任务的机制，适用于局部对象离开作用域、delete动态对象等场景，须声明为public、noexcept，避免抛异常、访问已销毁成员或启动新线程。
析构函数是唯一可靠的方式
对象生命周期结束时自动执行任务，C++ 中只有析构函数（~ClassName()）能保证被调用——前提是对象不是用 std::abort()、std::exit() 强制终止，也没发生栈溢出或未定义行为。
析构函数在以下场景被调用：局部对象离开作用域、动态分配对象被 delete、成员对象随宿主对象销毁、临时对象生命周期结束。它不依赖 RAII 外部机制，是语言级保障。
- 必须是 public、non-virtual（除非基类需要多态销毁）且无参数
- 不能被显式调用（除在 placement new 场景下手动析构，但极少见）
- 若类有虚函数，析构函数应声明为
virtual，否则派生类析构逻辑可能被跳过
避免在析构函数里抛异常
析构函数中抛出未捕获异常会导致 std::terminate() 直接终止程序——这是 C++ 标准强制规定，无法绕过。
常见踩坑点：在析构中调用可能抛异常的函数（如 std::ofstream::close()、网络库的同步关闭、std::mutex::unlock() 在未加锁状态下调用）。
立即学习“C++免费学习笔记（深入）”；
- 用
noexcept显式标注析构函数（C++11 起默认隐含noexcept(true)，但建议写明） - 对可能失败的操作做静默处理或记录日志（如
if (file.is_open()) file.close();） - 把需异常处理的清理逻辑提前到普通成员函数中，在对象销毁前主动调用
需要延迟/异步执行？别在析构里做
析构函数执行期间，对象的成员变量已按逆声明顺序开始销毁，虚表指针可能失效，this 指针处于“半销毁”状态。此时启动线程、发信号、调用回调、访问其他全局单例，极易引发未定义行为。
典型错误示例：~Logger() { std::thread([]{ flush_to_disk(); }).detach(); } —— 线程可能在析构结束后才真正运行，访问已销毁的缓冲区。
- 延迟任务应移交到独立生命周期的组件（如全局
std::shared_ptr<taskqueue></taskqueue>） - 使用
std::at_quick_exit()或std::atexit()仅适用于整个进程退出前的简单清理，不绑定对象实例 - 更安全的做法是显式调用
shutdown()或finalize()成员函数，由使用者控制时机
智能指针和 RAII 容器已经帮你做了大部分事
不必为每个资源都手写析构逻辑。优先用标准库提供的 RAII 封装：用 std::unique_ptr 管理动态内存，std::fstream 自动关闭文件，std::lock_guard 自动释放互斥量。
自定义类只需在析构函数中释放「非 RAII 封装」的资源：裸指针（没包进智能指针）、系统句柄（int fd、HANDLE）、C 风格内存（malloc/ free）、手动注册的回调 ID 等。
- 检查是否重复释放（如多次
delete ptr）——析构函数可能被意外调用两次（例如移动后又析构） - 移动构造/赋值后，原对象析构时指针应已置为
nullptr，否则二次 delete 崩溃 - 用
std::shared_ptr的自定义 deleter 可以把清理逻辑外提，让析构函数保持空或极简
析构函数表面简单，实际约束极多：不能抛异常、不能依赖其他对象完整状态、不能跨线程触发、不能做耗时操作。真正健壮的自动清理，靠的是前期资源封装设计，而不是在析构里“补救”。
