std::is_destructible 在编译期约束模板参数是否具备可用析构函数，用于容器move构造、智能指针reset等场景；要求T为完整类型，对void、引用、抽象类、不完整数组等恒为false，且不检查operator delete或异常规范。
std::is_destructible 在什么场景下真正有用？
它不是用来“运行时检测对象能不能 delete”，而是编译期做约束——比如模板函数只接受能安全析构的类型，避免 T{} 析构时报错或未定义行为。典型场景是容器类的 move 构造、智能指针的 reset、或者自定义分配器中清理资源前的静态检查。
常见错误现象：写了 static_assert(std::is_destructible_v<t>)</t> 却发现编译不过，其实是因为 T 是不完整类型（比如前置声明的 class），而 std::is_destructible 要求类型必须完整才能判断析构函数是否可访问、是否非 deleted。
- 仅当
T是完整类型且析构函数存在、可访问、未被= delete时，std::is_destructible_v<t></t>才为true - 对
void、引用、抽象类（无析构定义）等，结果恒为false - 数组类型如
int[5]可析构，但int[]（不完整数组）不行
为什么 std::is_destructible_v<T> 有时返回 false，但 T 实际上能 delete？
因为 std::is_destructible 检查的是「隐式析构可行性」，不是「delete 表达式能否通过」。它不考虑 delete 是否能找到 operator delete，也不管析构函数体里有没有抛异常——只看类型是否有可用的析构函数声明。
典型反例：class A { ~A() = default; }; 和 class B { ~B() = delete; };，前者 std::is_destructible_v<a></a> 为 true，后者为 false；但如果你写 A* p = new A; delete p; 和 B* p = new B; delete p;，后者在 delete 时才报错（链接期或运行期 UB），而 std::is_destructible 已提前拦住了。
立即学习“C++免费学习笔记（深入）”；
-
std::is_destructible不检查 operator delete 是否匹配，也不检查析构函数是否noexcept - 对带 private 析构函数的类，若当前作用域不可见，结果也是
false（哪怕友元或成员函数里能调用） - 注意别和
std::is_trivially_destructible混用：后者要求析构函数是 trivial 的（即编译器生成、无副作用），范围更窄
如何在模板中安全使用 is_destructible 做 SFINAE 或 constrain？
直接用 static_assert 最简单，但会硬报错；想实现“该模板对不可析构类型自动禁用”，得用 requires 或 enable_if。
template<typename T>
requires std::is_destructible_v<T>
void safe_cleanup(T* ptr) {
if (ptr) { ptr->~T(); }
}或者 C++17 以前：
template<typename T, typename = std::enable_if_t<std::is_destructible_v<T>>>
void safe_cleanup(T* ptr) { ... }- 用
requires更清晰，错误信息也更友好（提示 “constraints not satisfied” 而非一长串模板展开） - 别在类模板参数列表里直接写
std::is_destructible_v<T>，C++ 不允许非类型模板参数依赖未实例化的 T - 如果 T 是模板参数且可能为 void，记得加
std::is_void_v<T>排除，否则std::is_destructible_v<void>是false，但你可能想特化处理
容易被忽略的兼容性坑：C++11 到 C++20 的行为差异
从 C++11 引入到 C++20，std::is_destructible 的语义没变，但实现细节有调整：早期标准库（如 libstdc++ 4.9）对某些带 deleted 析构函数的嵌套类判断不准；MSVC 2015 前对 friend 析构函数的支持也有问题。
性能影响几乎为零——它纯属编译期常量表达式，不生成任何运行时代码。
- Clang 10+、GCC 9+、MSVC 2019 16.8+ 都已稳定支持，无需额外宏开关
- 不要试图在
constexpr if外用std::is_destructible_v<T>控制分支逻辑——它只是 bool 值，不能替代类型系统本身 - 如果用在 concept 中，注意它不递归检查成员类型：即使
T可析构，T的某个成员变量不可析构，也不会让std::is_destructible_v<T>变false
最麻烦的其实是间接依赖：比如模板接受 Container<T>，而 Container 内部用了 std::is_destructible_v<T> 做约束，此时你传入一个看似合法的 T，却因 Container 的实现细节失败——这种链式约束很难一眼定位。
