std::is_trivially_constructible 不能判断 constexpr 构造可行性，因其仅检查平凡性而非字面量性、constexpr 修饰及常量表达式初始化；唯一可靠方法是直接尝试 constexpr 初始化并观察编译错误。
不能靠 std::is_trivially_constructible 判断——它只管“编译器能不能跳过构造函数”，和“能不能放进 constexpr 上下文”完全无关。
为什么 std::is_trivially_constructible 不是你要找的工具
这个 trait 检查的是“平凡构造”：类没用户定义的构造/析构/拷贝/移动，所有成员也都满足。它不关心构造函数有没有 constexpr 修饰，也不检查成员类型是否字面量（std::string 就直接否决一切 constexpr 构造）。
常见错误现象：
-
std::is_trivially_constructible_v<:array>> == true</:array>，但constexpr std::array<int> a{};</int>合法； -
std::is_trivially_constructible_v<:pair std::string>> == false</:pair>，但更关键的是——它根本不可能constexpr构造，因为std::string不是字面量类型； - 你自己写的空类，
std::is_trivially_constructible返回true，但若含一个const int x = rand();成员，照样无法constexpr构造。
真正能验证的唯一可靠方式：让编译器报错
标准库没有 std::is_constexpr_constructible，因为是否可常量构造依赖具体构造函数签名、所有间接成员的字面量性、初始化表达式是否为常量表达式——这些无法静态断言。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 写一个
constexpr变量，用目标类型和参数初始化它； - 如果编译失败，错误信息里通常会指出哪一步破坏了常量求值（比如 “call to non-constexpr function”、“non-literal type”、“subobject is not usable in a constant expression”）；
- 不要依赖运行时测试或 SFINAE 技巧——它们只能测“能否实例化”，不是“能否在常量上下文中求值”。
示例：
struct S {
int x;
constexpr S(int a) : x(a) {}
};
constexpr S s1(42); // OK
struct T {
std::string s;
constexpr T() = default; // 这个 constexpr 是无效的
};
// constexpr T t; // 编译错误：std::string is not a literal type
手动检查的三个硬性条件
若想提前预判，必须逐层确认：
- 该类型的**每个参与构造的构造函数**都显式声明为
constexpr； - 所有**非静态数据成员**类型都是字面量类型（
int、std::array、constexpr构造的std::pair等），且其初始化表达式本身是常量表达式； - 所有**基类**（如有）也满足上述两条，并且不能是虚继承。
注意：std::is_literal_type 在 C++17 已弃用，C++20 起彻底移除，别再用它。
容易被忽略的边界点
即使所有成员都是字面量类型、构造函数也标了 constexpr，仍可能失败：
- 构造函数体里调用了非
constexpr函数（哪怕只是std::abs，它在 C++20 前不是constexpr）； - 用了
this->member = expr形式的赋值（C++14 起允许，但 C++11 不允许）； - 成员是
const引用，但初始化绑定到非常量表达式对象； - 模板类中，模板参数本身不是常量表达式（例如
template<int N> struct X { constexpr X() : n(N) {} int n; };，但N来自非constexpr上下文）。
最稳妥的做法始终是：写一行 constexpr 初始化，看编译器怎么说。
