应使用 std::is_trivially_move_constructible_v 判断类型是否拥有平凡移动构造函数，但它不保证该函数会被实际调用；需结合 std::is_move_constructible_v 和 std::is_nothrow_move_constructible_v 等 trait 综合判断移动语义是否生效。
直接结论：用 std::is_trivially_move_constructible_v<t></t> 判断，但必须注意它只检测「移动构造函数是否平凡」，不保证该函数实际被调用——编译器仍可能因优化或 SFINAE 选择其他路径。
为什么 std::is_trivially_move_constructible 的结果有时和运行行为不符？
这个 trait 检查的是类型 T 是否「拥有一个平凡的移动构造函数」，而不是「当前上下文是否会调用它」。常见脱节场景包括：
- 类定义了用户自定义的拷贝构造函数但没声明移动构造函数 → 移动构造函数被隐式删除，
std::is_trivially_move_constructible_v<t></t>为false，即使你写了T t2 = std::move(t1);，实际调用的可能是拷贝构造（如果可访问） - 类有
= default的移动构造函数，但成员中含非平凡类型的子对象（如std::string）→ 整体移动构造函数非平凡，trait 返回false，但语义上仍是“高效移动” - 模板推导中，
T&&绑定到 const 类型时，移动构造不参与重载决议 → trait 为true，但代码根本不会触发移动
std::is_trivially_move_constructible 的真实检查逻辑
它等价于：std::is_trivially_constructible_v<t t></t>，即「能否用 T&& 类型的实参，平凡地构造 T」。关键判定条件是：
- 类必须有可访问的移动构造函数（显式声明、
= default，或编译器隐式生成） - 该移动构造函数必须满足「平凡」定义：未被用户定义、无虚基类、所有非静态数据成员和基类的移动构造函数也平凡
- 注意：平凡 ≠ 不抛异常 ≠ 零开销；例如
std::array<int></int>是平凡移动可构造的，但底层仍是 1000 次 int 赋值
示例：
立即学习“C++免费学习笔记（深入）”；
struct Trivial { int x; };
struct NonTrivial { std::string s; };
static_assert(std::is_trivially_move_constructible_v<Trivial>); // ✅
static_assert(!std::is_trivially_move_constructible_v<NonTrivial>); // ❌（std::string 移动构造非平凡）
真正关心“能不能安全移动”时，该看什么？
如果你目标是「避免深拷贝、确保移动语义生效」，单靠 std::is_trivially_move_constructible 不够。应组合检查：
- 先确认移动构造函数存在且未被删除：
std::is_move_constructible_v<t></t> - 再看是否无抛出：
std::is_nothrow_move_constructible_v<t></t>（对容器扩容、std::vector::push_back等场景更关键） - 若需零成本位移（如 memcpy 级别），则必须同时满足：
std::is_trivially_move_constructible_v<t> && std::is_trivially_destructible_v<t> && std::is_standard_layout_v<t></t></t></t>—— 这才接近 POD-like 可 memcpy 的安全边界
别漏掉：即使 T 本身平凡可移动，其模板参数（如 std::vector<T>）的行为还取决于分配器和元素类型，不能只看顶层 trait。
最容易被忽略的一点：这个 trait 对引用类型、函数类型、void 返回 false，但它对 const T 或 T& 的判断结果与 T 无关——因为引用和 cv-qualified 类型本身不可构造，trait 直接失效。实际写泛型代码时，务必先 std::remove_reference_t 和 std::remove_cv_t。
