constexpr变量声明成功需满足三条件：所有构造函数为constexpr、所有非静态成员为字面量类型、基类及成员构造亦递归满足；std::is_trivially_constructible与此无关，唯一可靠验证法是直接写constexpr T obj{}让编译器报错。
直接写 constexpr T obj{};，编译过就支持，不过得注意它背后有三层硬约束——光靠类型特征根本骗不过编译器。
为什么 std::is_trivially_constructible 完全没用
这个 trait 只管“编译器能不能跳过构造函数”，和“能不能放进 constexpr 上下文”毫无关系。它不检查构造函数有没有 constexpr 修饰，也不管成员是不是 std::string 这种非字面量类型。
-
std::is_trivially_constructible_v<:array>></:array>是true，但constexpr std::array<int> a{};</int>能过，靠的不是平凡性，而是std::array的constexpr构造函数 -
std::is_trivially_constructible_v<:pair std::string>></:pair>是false，但真正致命的是std::string本身不是字面量类型，连constexpr构造的资格都没有 - 你自己写的空类，即使
std::is_trivially_constructible返回true，只要加了const int x = rand();，照样无法constexpr构造
必须手动验证的三个条件
想提前预判，就得一层层翻代码，不能只靠模板元编程蒙混过关：
- 该类型的**每个参与构造的构造函数**都显式声明为
constexpr（包括= default形式），且函数体里不能出现new、try、虚函数调用、未定义行为等禁止项 - 所有**非静态数据成员**类型必须是字面量类型：比如
int、std::array、std::pair<int double></int>（前提是其成员也满足），但std::string、std::vector、含用户析构函数或虚基类的类型一律排除 - 基类、成员的构造函数也得递归满足上述两条；哪怕一个
const std::string_view成员，只要它的初始化依赖运行时值，整个构造就崩
最可靠实操：让编译器当场报错
标准库没有 std::is_constexpr_constructible，因为是否可常量构造取决于具体构造函数签名、所有间接成员的字面量性、初始化表达式是否为常量表达式——这些无法静态断言。
立即学习“C++免费学习笔记（深入）”；
- 在全局或命名空间作用域加一行：
constexpr T test_instance{}; - 若编译通过，说明该类型可在常量表达式中安全构造
- 若失败，看错误信息：
call to non-constexpr function指向构造函数问题，non-literal type指向成员类型违规，subobject is not usable in a constant expression暴露初始化表达式本身不合法 - 对带参构造，改用
constexpr T test_instance{arg1, arg2};，并确保所有实参都是常量表达式（比如42、constexpr int x = 3;）
最容易被忽略的一点：即使所有条件看似满足，只要某个成员的初始化用了非常量表达式（比如 const int y = some_runtime_value;），或者构造函数里调用了非 constexpr 函数，constexpr 变量声明就会静默失败——错误信息往往藏在深层子对象里，得顺着报错栈一层层往上查。
