std::is_literal_type在C++17中被移除，因其语义模糊且被更正交的trait组合替代；应改用std::is_trivially_destructible_v、std::is_trivially_copyable_v和std::is_trivial_v联合判断。
std::is_literal_type 在 C++17 中已被移除，直接使用它会编译失败——这不是你配置错了，是标准删了。
为什么 std::is_literal_type 编译不过
C++11 引入 std::is_literal_type，但它的定义依赖于当时模糊的“字面值类型”语义（比如是否允许 constexpr 构造函数、静态成员是否可内联初始化等）。C++14 开始松动限制，C++17 索性废弃该 trait，并用更正交、更可控的底层特性替代。
- 它在 libstdc++（GCC）和 libc++（Clang）中从 C++17 起标记为 deprecated，链接时可能报
error: 'is_literal_type' is deprecated - MSVC 从 19.10（VS 2017 15.0）起同样禁用，启用
/std:c++17后直接不识别 - 即使强制用
/std:c++14，它对含constexpr成员函数或非静态数据成员为用户自定义类型的类，判定也常不可靠
替代方案：用 std::is_trivially_destructible + std::is_trivially_copyable + std::is_literal_type_v 的等价组合
现代判断“是否能用于 constexpr 上下文”的实际需求，本质是检查：能否在编译期构造、析构、复制？是否所有非静态成员都满足该条件？因此应组合多个基础 trait：
-
std::is_trivially_destructible_v<t></t>：析构函数不能有副作用，且必须是 trivial（编译器生成或 = default） -
std::is_trivially_copyable_v<t></t>：内存可按字节拷贝，无用户定义拷贝/移动操作 -
std::is_trivial_v<t></t>（可选加强）：进一步要求默认构造、拷贝、移动、析构全 trivial —— 覆盖大部分 literal type 场景 - 若需支持 C++14 风格的 constexpr 构造，还需手动检查是否存在
constexpr构造函数（无法用 trait 直接查，需 SFINAE 或std::is_constructible_v<t args...></t>配合 constexpr 上下文验证）
示例（C++17+）：
立即学习“C++免费学习笔记（深入）”；
template <typename T>
constexpr bool is_effectively_literal_v =
std::is_trivially_destructible_v<T> &&
std::is_trivially_copyable_v<T> &&
std::is_trivial_v<T>;
容易被忽略的坑：union、static 成员、constexpr 构造函数的影响
即使满足上述 trait 组合，仍可能在 constexpr 上下文中失败：
- 含
union的类：若 union 有非 trivial 成员（如std::string），即使整体is_trivial_v为 false，也会导致无法实例化 constexpr 对象 - 静态数据成员：C++17 前要求
static constexpr成员必须有定义（ODR-used 时），否则链接失败；C++17 起 inline 可缓解，但未声明为inline仍可能触发 ODR 违规 - constexpr 构造函数本身合法 ≠ 类型是 literal type：例如
struct A { constexpr A() {} int x; };中A在 C++11 是 literal type，但在 C++17 因int x不是 const-init 安全而受限；实际能否用于constexpr A a;还取决于初始化方式
真正关键的不是“叫不叫 literal type”，而是你的对象是否能在 constexpr 函数里被构造、赋值、返回。建议在关键路径上直接写测试用例，而非依赖 trait 推理——trait 组合只是近似，编译器报错才是最终判决。
