类在constexpr上下文中可安全析构仅取决于其析构函数是否为平凡析构，而非是否显式定义；std::is_trivially_destructible_v为true是必要条件，但还需满足所有基类和非静态成员同样平凡可析构、无虚函数/虚基类、无deleted或volatile成员。
类在 constexpr 上下文中能被安全析构，**只取决于其析构函数是否为平凡析构（trivial destructor）**，而不是“有没有写析构函数”或“是不是空实现”。这是 C++20 起对 constexpr 生命周期的硬性门槛。
std::is_trivially_destructible_v 是必要但不充分条件
这个类型特性返回 true，说明 T 的析构函数是编译器自动生成、无用户逻辑、无副作用的——这是 constexpr 析构的起点。但它不保证整个类型满足字面类型（literal type）全部要求。
-
std::is_trivially_destructible_v<t></t>为false→ 类型 绝对不可 用于 constexpr 析构 -
std::is_trivially_destructible_v<t></t>为true→ 还需检查：T所有非静态成员、所有基类也必须满足该特性；不能含虚函数、虚基类；不能有= delete的析构函数；不能有volatile非静态成员 - 常见误判：写
~C() {}（空花括号）→ 用户提供析构函数 → 非平凡 →std::is_trivially_destructible_v<c></c>为false
含 std::string / std::unique_ptr 成员的类基本无法 constexpr 析构
C++20 标准下，std::string 和（C++20 前的）std::unique_ptr 的析构函数都不是平凡的，它们内部涉及运行时资源释放逻辑，直接导致外层类的析构也被标记为非平凡。
-
std::string：即使为空，其析构仍需检查内部指针并可能调用delete[]→ 非平凡 -
std::unique_ptr<int></int>：C++23 起才支持 constexpr 析构，且仅限 GCC 13+、Clang 16+；C++20/C++26 当前主流实现中仍不满足std::is_trivially_destructible_v -
std::shared_ptr：C++26 才引入 constexpr 支持，且仅限编译期构造+编译期销毁的封闭场景；运行时分配的shared_ptr与 constexpr 析构无关
constexpr 构造成功 ≠ constexpr 析构可行
很多人在 constexpr T obj{...}; 编译通过后就默认析构也没问题，这是典型陷阱。C++20 对 constexpr 对象生命周期各阶段独立校验：构造、复制、移动、析构，每一步都必须满足字面类型要求。
立即学习“C++免费学习笔记（深入）”；
- 构造成功只说明构造函数是
constexpr、成员初始化是常量表达式 - 析构失败的常见信号：
static_assert报错提示 “not a constant expression” 或 “call to non-constexpr function”，源头往往就是析构函数 - 继承链中只要有一个基类带虚析构（哪怕你没显式写），派生类析构即为非平凡 → 整个类型失去 constexpr 析构资格
-
[[no_unique_address]]不豁免成员类型的析构平凡性：如果被压缩的成员本身析构非平凡，它仍会传导到外层类
C++26 constexpr std::shared_ptr 的析构边界很窄
C++26 确实允许 constexpr std::shared_ptr，但它不是“让 shared_ptr 变成 constexpr 类型”，而是限定在编译期可完全推导生命周期的极简路径上。
- 仅支持在
constexpr函数内调用std::make_shared构造，且对象必须在同作用域内解引用或销毁（不能逃逸） - 禁止任何运行时内存操作：不能用
reset()、不能用get()后转为裸指针再 delete，不能参与循环引用 - 引用计数更新必须在编译期静态可判定——这意味着实际只能用于单次构造 + 单次析构的线性流程，复杂控制流会直接失败
- 当前（2026 年 5 月）GCC 14/Clang 17 尚未完全实现该特性；MSVC 仅在 `/std:c++26` 下部分支持，且对析构路径极其敏感
真正容易被忽略的是：**平凡析构不是靠“不写析构函数”就能自动获得的，而是整个类型拓扑结构（成员、基类、cv 限定符、虚性）共同决定的结果**。一个看似简单的 struct，只要嵌套了一层 std::optional<:string></:string>，就足以让它在 constexpr 析构场景中彻底失效。
