要确认类型能否 constexpr 构造，必须用 constexpr t t{}; 全局声明触发编译器验证；仅看是否有默认构造函数或 is_trivially_constructible 无效，需递归检查构造函数、成员及基类是否全为字面量类型且满足 constexpr 约束。
要确认一个自定义或标准库类型能否在 constexpr 上下文中安全构造，不能只看它有没有默认构造函数，必须让编译器当场验证——因为哪怕一个 const std::string_view 成员初始化依赖运行时值，整个构造就失效。
最可靠实操：用 constexpr 声明触发编译器报错
这一步操作起来很简单，直接在全局作用域写一行声明即可。
第一步：在任意 .cpp 或头文件的命名空间顶层添加 【constexpr T test{};】（T 替换为你想测的类型）。
第二步：保存并编译。若通过，说明该类型支持常量构造；若失败，根据错误信息定位问题根源。
第三步：若类型有带参构造，改用 【constexpr T test{arg1, arg2};】，确保传入的每个实参本身也是常量表达式（如字面量、constexpr 变量），否则错误会掩盖真正的构造限制。
注意：不要放在函数体内测试——局部 constexpr 声明可能因作用域提前退出而绕过部分检查，全局声明才能暴露全部约束。
手动预判三条件（适用于无法立即编译的场景）
方法一：查构造函数是否全为 constexpr
打开该类型的定义，确认所有参与构造的构造函数（含 = default）都显式标注 constexpr，且函数体中不含 new、try、虚函数调用、goto、未定义行为等禁止项。
方法二：扫非静态成员是否全为字面量类型
逐个检查类中每个非静态数据成员的类型：int、long、std::array
方法三：递归验证基类与成员的构造路径
即使当前类所有成员都是 int，只要它继承自某个含 std::string 成员的基类，或某个成员对象自身构造函数不是 constexpr，整条链就断裂。必须沿继承关系和成员嵌套逐层展开验证。
为什么 std::is_trivially_constructible 完全不可信
这个 trait 只回答“编译器能否跳过构造函数”，不回答“能不能放进 constexpr 上下文”。
std::is_trivially_constructible_v<:array>> 返回 true，但 constexpr 构造能过，靠的是 std::array 显式定义的 constexpr 构造函数，而非平凡性。
你写的空类即使 is_trivially_constructible 返回 true，只要加了 const int x = rand();，就立刻失去 constexpr 构造资格——因为 rand() 是运行时函数，初始化表达式本身不合法。
std::is_literal_type_v 在 C++17 已被弃用，它连构造函数是否存在都不检查，更不会验证成员是否真能常量初始化。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
