std::is_nothrow_destructible 是编译期断言工具，用于确保类型析构函数不抛异常；典型场景包括 vector realloc、placement new/显式析构、自定义分配器及无锁数据结构等，需配合 static_assert 显式验证。
std::is_nothrow_destructible 是什么，什么时候真有用
它不是性能优化的银弹，而是编译期断言工具——只在你明确需要「析构函数绝不能抛异常」的场景下才有意义。典型如 std::vector 在 realloc 时要移动元素，若类型析构可能抛异常，标准库就不得不走更保守的拷贝+销毁路径；又比如自定义容器里做 placement new + 显式析构时，你得确保 ~T() 不会中途炸掉。
怎么查一个类型是否满足 nothrow destructible
直接用 static_assert 配合 std::is_nothrow_destructible_v 最可靠：
struct Good {
~Good() noexcept {} // 显式标记
};
struct Bad {
~Bad() { throw 42; } // 隐式可能抛
};
static_assert(std::is_nothrow_destructible_v<good>, "Good must be nothrow-destructible");
static_assert(!std::is_nothrow_destructible_v<bad>, "Bad correctly rejected");</bad></good>
注意三点：
-
noexcept必须显式写在析构函数声明上，哪怕函数体空也不自动推导 - 基类或成员中任一析构函数非
noexcept，整个类型就不是std::is_nothrow_destructible - 模板类型（如
std::vector<t></t>）要对T单独检查，别默认容器本身“安全”
和内存管理直接挂钩的关键点
真正影响内存操作的是「析构能否失败」这个事实，而非这个 trait 本身。它只是让你把检查提前到编译期：
-
std::allocator_traits<a>::destroy</a>不保证异常安全，但如果你用自定义 allocator 管理裸内存，且依赖~T()不抛异常来跳过 try-catch，则必须确认std::is_nothrow_destructible_v<t></t> - 写无锁数据结构时，若在析构中释放资源（如 refcount 减为 0 时 delete），而该析构又可能抛异常，就会破坏 RAII 的基本契约
- 某些内存池实现会复用对象内存，调用
std::destroy_at后立即重用地址——此时若~T()抛异常，后续构造就发生在未完全清理的对象上
容易被忽略的陷阱
最常踩的坑是误以为「没写 throw() 就安全」：
- C++11 起默认析构函数是
noexcept(true)，但一旦你显式定义了析构函数（哪怕空实现），它就变成noexcept(false)——除非你手动加noexcept - 继承链中只要有一个基类析构没标
noexcept，派生类自动失去std::is_nothrow_destructible属性 - 使用
std::unique_ptr<t d></t>时，D的析构行为不参与判断，只有T的析构才计入std::is_nothrow_destructible
这类细节不靠 static_assert 基本发现不了，等 crash 在生产环境出现时已经晚了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
