std::is_literal_type在C++17中被移除，因语义模糊且被constexpr语义取代；替代方案需按场景选择：NTTP用structural type判定，constexpr变量初始化应实测构造表达式。
std::is_literal_type 在 C++17 中已被移除，直接使用它会编译失败——别再查旧文档或复制过时代码了。
为什么 std::is_literal_type 编译不过？
C++17 起，std::is_literal_type 被正式废弃并删除。它曾用于判断类型是否为“字面值类型”（literal type），但标准发现该 trait 语义模糊、与实际常量求值需求脱节，且被 constexpr 语义逐步取代。
- Clang/GCC 在 C++17 模式下遇到
std::is_literal_type会报错：error: 'is_literal_type' is not a member of 'std' - 即使在 C++14 中启用，它对用户自定义类的判定也仅检查“是否有 constexpr 构造函数 + 所有非静态成员可字面值化”，不反映真实
constexpr上下文可用性 - 它无法识别 C++17 引入的
constexpr if或constexpr成员函数带来的新能力
替代方案：用 std::is_trivially_copyable + std::is_default_constructible 粗略逼近？
没有完全等价的直接替代，但若你真正关心的是“能否安全放入 constexpr 变量或作为模板非类型参数（NTTP）”，应分场景处理：
- 对于 C++20 NTTP（如
template<auto v> struct X</auto>），类型必须是 structural type：即满足std::is_trivially_copyable_v<t></t>且所有非静态数据成员及基类均为 structural type（递归判定），不能有虚函数/虚基类/不可复制成员 - 若目标是“能否声明为
constexpr T x{...}”，关键不是类型本身，而是初始化表达式是否满足constexpr约束——此时应测试具体构造，而非依赖 trait -
std::is_trivially_destructible_v<t></t>和std::is_trivial_v<t></t>可辅助判断底层内存行为，但和“字面值”无直接对应关系
实际检测：写个 SFINAE 或 consteval 尝试构造
最可靠的方式，是让编译器在 constexpr 上下文中尝试使用该类型——这比任何 trait 更贴近真实约束：
立即学习“C++免费学习笔记（深入）”；
template<typename T>
consteval bool can_be_constexpr_constructed() {
// 若 T 无默认构造函数，可改用 T{some_args}
constexpr T t{};
return true;
}
static_assert(can_be_constexpr_constructed<int>(), "");
static_assert(!can_be_constexpr_constructed<std::vector<int>>(), ""); // 编译失败
- 此方法强制触发实际常量求值，捕获所有隐式要求（如基类/成员的 constexpr 构造、无动态内存、无运行时副作用）
- 注意：C++20
consteval函数只能在编译期求值，失败时直接报错，比constexpr函数更严格、更适合做这类探测 - 不能用于不完整类型或含私有构造函数的类型（SFINAE 不适用），但这类类型本就无法在外部构造，通常也不在检测范围内
真正难处理的是跨标准版本兼容和语义迁移：C++14 的“字面值类型”定义和 C++20 的“允许在常量求值中使用的类型”已不是一回事，硬套旧逻辑容易误判。与其纠结 trait 名称，不如明确你要解决的具体问题——是模板参数限制？还是 constexpr 容器初始化？然后针对性验证。
