最可靠方式是用std::is_trivial_v<T>（C++17起）或std::is_trivial<T>::value（C++11起），它严格按标准定义编译期判定类型是否平凡，要求默认构造、析构、拷贝/移动全部平凡且所有成员也平凡，零开销、可移植、语义准确。
用 std::is_trivial 编译期判断最可靠
直接用 std::is_trivial<T>::value，这是标准库提供的唯一可移植、语义准确的方式。它在编译期求值，零开销，且严格遵循 ISO C++ 标准对“琐碎类型”的定义（即同时满足琐碎默认构造、琐碎析构、琐碎拷贝/移动等）。
常见错误是手动检查是否有用户定义的构造函数或虚函数——这既不充分也不必要。例如：含 constexpr 默认构造函数的类仍可能是琐碎的（只要不显式定义为 default 以外的形式）；而仅含虚函数但无虚基类、无用户定义特殊成员的类，在 C++17 起也可能是琐碎的（虚函数本身不破坏琐碎性）。
实操建议：
- 始终优先使用
std::is_trivial_v<T>（C++17 起推荐写法） - 不要依赖 IDE 的“跳转到定义”或编译器警告来推断——它们不保证符合标准定义
- 若需 SFINAE 或
requires约束，直接用std::is_trivial_v<T>作为约束条件
注意 std::is_trivially_copyable 和 std::is_trivial 的区别
二者常被混淆，但语义不同：std::is_trivial 要求所有特殊成员函数都琐碎，而 std::is_trivially_copyable 只要求对象能通过 memcpy 安全复制（即无非平凡析构、无虚基类、所有非静态成员可 trivially copyable）。一个类型可以是 trivially copyable 但不是 trivial（比如含用户定义的 trivial 默认构造函数）。
立即学习“C++免费学习笔记（深入）”；
典型误用场景：
- 想做 POD 类型兼容性检查时，误用
std::is_trivial替代std::is_pod（后者已弃用，实际应组合std::is_trivial+std::is_standard_layout） - 做 memcpy 优化时，只检查
std::is_trivial——其实只需std::is_trivially_copyable - 在模板中对类型做 layout 保证断言时，漏掉
std::is_standard_layout_v<T>
Clang/GCC 的 __is_trivial 内置宏慎用
Clang 和 GCC 提供 __is_trivial(T) 这类编译器内置宏，行为接近但不完全等价于 std::is_trivial。它可能在某些边缘情况下返回不同结果（如涉及模板参数推导或未实例化的类模板），且不具备跨编译器可移植性。
除非你明确在写编译器特定的底层库，并已验证其行为与标准一致，否则不应使用。尤其要避开以下情况：
- 在头文件中用
__is_trivial做 SFINAE 条件（MSVC 不识别，导致编译失败） - 用于 static_assert 错误信息中——
std::is_trivial的诊断更清晰，且能触发更友好的模板错误提示 - 替代
std::is_trivial做 ABI 兼容性判断（内置宏不参与 ODR，可能导致不同 TU 中判定结果不一致）
运行时无法判断，别试图绕过编译期限制
没有合法的运行时方法能确定一个类型是否为琐碎类型。任何尝试用 typeid、RTTI、dynamic_cast 或反射（如 C++20 的 std::reflect 提案尚未落地）都是徒劳的——琐碎性是编译期属性，不生成运行时信息。
如果看到类似“运行时检测是否可 memcpy”的需求，本质是想确认 std::is_trivially_copyable_v<T>，但它依然只能在编译期求值。强行拖到运行时（比如用函数指针表模拟）不仅无效，还会掩盖真正的设计问题：该类型本就不该在运行时才决定内存操作方式。
容易忽略的一点是：即使一个类模板的部分特化是琐碎的，其主模板本身可能无法被 std::is_trivial 推导（因未完成实例化），此时必须确保类型已完成具现化再检查。
