std::is_trivially_copyable_v 是 memcpy 的安全前提，要求 t 为完整类型且满足平凡复制、移动、析构三条件；含虚函数、const/引用成员、显式特殊函数或前置声明均导致 false。
直接结论：用 std::is_trivially_copyable_v<t></t> 判断，但必须确保类型 T 是完整类型，且在模板实例化点已定义完毕 —— 否则编译失败或结果为 false（不是“不准”，是“不合法”）。
为什么 std::is_trivially_copyable_v 有时返回 false 即使类看起来“只是 memcpy”
常见错误是把未完成定义的类传给该 trait：
struct A; // 前向声明 static_assert(std::is_trivially_copyable_v<a>); // ❌ 编译错误：A 是不完整类型</a>
即使后续定义了 A，只要 static_assert 出现在定义前，trait 就无法工作。C++ 标准要求 std::is_trivially_copyable 的模板参数必须是完整类型（否则行为未定义，主流编译器直接报错）。
- 类定义必须在 trait 使用点之前完成（包括所有基类、成员类型的定义）
- 模板中若依赖 SFINAE 或
constexpr if判断，也要确保推导时类型已完整 - 注意头文件包含顺序：如果
A定义在a.h，而 trait 在b.cpp中使用，必须#include "a.h"，不能只靠前向声明
trivially copyable 的实际判断条件比“没写拷贝函数”更严格
满足 trivially copyable 需同时满足三个条件：可平凡复制（trivial copy）、可平凡移动（trivial move）、可平凡析构（trivial destructor），且不能有非平凡的虚函数表布局干扰。常见破坏点：
- 显式定义了任何拷贝/移动构造函数或赋值运算符（哪怕写成
= default，也需确认是否真被编译器视为 trivial —— 比如基类/成员不 trivial 就会传染） - 含有引用成员或 const 非静态数据成员（即使没自定义函数，也不 trivial）
- 虚函数或虚继承（哪怕只有一个
virtual函数，就破坏 layout 可预测性） - 析构函数被显式定义（哪怕空实现或
= default，若所在类有虚基类等复杂情况，也可能非 trivial）
示例：
struct Bad {
const int x = 0; // ❌ const 成员 → 不 trivially copyable
Bad() = default;
};
而下面这个是 OK 的：
struct Good {
int x;
double y;
// 无虚函数、无 const/引用成员、无自定义特殊成员函数 → trivially copyable
};
运行期无法判断，也不能靠 memcpy 行为反推
有人尝试用 memcpy 赋值后比较二进制是否一致来“验证” trivially copyable —— 这不可靠，且危险：
- 未定义行为：对非 trivially copyable 类型调用
memcpy是 UB（比如含虚函数指针的对象，memcpy 会复制旧 vptr，导致悬空） - padding 字节内容未指定，
memcmp可能因 padding 差异误判 - 编译器可能优化掉看似无用的 memcpy，导致测试失效
-
std::is_trivially_copyable_v是编译期常量表达式，唯一权威依据
如果你需要跨 ABI 传递或做序列化，必须依赖该 trait 结果，而不是运行时试探。
最容易被忽略的是：模板内部对类型 T 的 trait 查询，必须保证 T 在该上下文是完整类型 —— 这往往藏在间接包含或延迟实例化的模板深处，错误信息却只报 “invalid use of incomplete type”，不容易联想到 trait 上。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
