类能否在constexpr上下文中安全析构，取决于编译器能否在编译期不执行任何运行时逻辑就完成销毁；绝大多数自定义类默认不可constexpr析构，哪怕仅声明空析构函数~T(){}也会失败。
类能不能在 constexpr 上下文中安全析构，不是看它“有没有析构函数”，而是看编译器能否在编译期**不执行任何运行时逻辑**就完成销毁。绝大多数自定义类默认不可 constexpr 析构，哪怕只加了一行空的 ~T() {} 就直接失败。
std::is_trivially_destructible_v 是必要但不充分条件
这个类型特征是第一道硬门槛：如果 std::is_trivially_destructible_v<T> 为 false，那该类型一定不能用于 constexpr 析构——编译器会直接报错。但它为 true 并不保证能用，因为 C++20 要求 constexpr 析构必须是 *trivial destructor*，而 trivial 的定义比“没写析构函数”更严格：
- 不能有用户提供的析构函数（哪怕内容为空，
~T() {}就已破坏 trivial 性） - 所有非静态成员和基类也必须是
std::is_trivially_destructible_v为true - 不能有虚函数、虚基类、
volatile非静态成员、被= delete的析构函数 - 继承链中若基类带虚析构（哪怕派生类没写），整个类型自动变为非平凡析构
用 constexpr 函数实测才是最终判决依据
类型特征只能筛掉明显不合格的，真正能不能用，得让编译器在常量表达式里走一遍完整生命周期。最简实测方式是写一个模板函数并触发 static_assert：
template<typename T>
constexpr bool is_constexpr_destructible() {
T t;
return true;
}
static_assert(is_constexpr_destructible<MyClass>(), "MyClass cannot be constexpr-destructed");
若编译失败，错误信息通常指向具体违规点：
立即学习“C++免费学习笔记（深入）”；
-
call to non-constexpr function→ 某个成员或基类的析构函数不是 constexpr（如含std::string、std::vector） -
not a constant expression→ 析构函数体内有禁止操作（如隐式调用delete、throw、asm） -
function does not satisfy constexpr requirements→ 析构函数声明了constexpr但实际违反约束（如含if或循环）
常见“看似合法”却翻车的成员类型
很多标准库类型在 C++20/C++23 前根本不支持 constexpr 析构，即使你把析构函数标成 constexpr 也没用——因为它们的内部实现依赖运行时行为：
-
std::string：C++20 前析构非平凡；C++23 起部分编译器（GCC 14+、Clang 17+）才开始实验性支持，仍需确认std::is_trivially_destructible_v<std::string> -
std::unique_ptr<int>：C++23 起才要求 constexpr 析构，旧版本直接失败 -
std::array<std::string, 2>：外层std::array是平凡析构，但内嵌std::string成员不是，整体传导为非平凡 - 用
[[no_unique_address]]包裹的非平凡类型：该属性不消除析构语义，只要成员析构非平凡，整个类就不可 constexpr 析构
真正能安全用于 constexpr 析构的，基本只有纯数据聚合体（POD）或手动控制的字面类型：整型、浮点、std::array<int, N>、std::pair<int, int> 等。一旦涉及资源管理（哪怕只是隐式堆内存释放），就大概率出局——这不是语法限制，而是编译期无法模拟运行时销毁逻辑的本质决定的。
