std::is_trivially_copyable仅是编译期断言memcpy安全，不自动优化；需手动用memcpy或依赖标准库在满足条件时自动降级为memmove。
std::is_trivially_copyable 不能直接“优化拷贝”，它只是编译期断言
它不改变行为、不生成更快代码，只告诉你：对这个类型做 memcpy 是安全的。真正的优化要靠你根据这个信息**手动选择 memcpy 路径**，或让标准库容器/算法在满足条件时自动启用底层优化（如 std::vector::resize 内部可能用 memmove）。
常见误用是以为加个 static_assert(std::is_trivially_copyable_v<t>)</t> 就能提速——其实什么也没变，只是加了层检查。
什么时候该手动用 memcpy 替代 operator= 或 copy constructor
仅当满足全部以下条件时，才值得手写 memcpy：
- 类型
T确实是std::is_trivially_copyable_v<t></t>为true - 你正在批量拷贝大量对象（比如数组、连续 buffer），且 profiler 明确指出拷贝构造/赋值成了瓶颈
- 你控制内存布局，确保源和目标地址对齐、无重叠（否则用
memmove）、且生命周期管理清晰（不触发析构/构造） - 你用的是 C++17 或更新标准（C++17 起
std::is_trivially_copyable语义更可靠；C++20 加了std::is_trivially_relocatable的雏形）
示例：
立即学习“C++免费学习笔记（深入）”；
struct alignas(16) Vec3 {
float x, y, z;
};
static_assert(std::is_trivially_copyable_v<Vec3>);
<p>// 安全的手动 memcpy 拷贝（假设 ptr_src/ptr_dst 已分配好）
std::memcpy(ptr_dst, ptr_src, n * sizeof(Vec3));
std::vector 和 std::copy 对 trivially copyable 类型的隐式优化
现代 libstdc++（GCC 9+）、libc++（Clang 10+）和 MSVC（19.20+）在检测到元素类型为 std::is_trivially_copyable_v<T> 时，会把 std::vector::assign、std::vector::insert、std::copy 等操作降级为 memmove 或 memcpy，无需你干预。
但注意：
- 这种优化依赖于迭代器类型：必须是原生指针或满足
std::is_pointer_v/std::is_contiguous_iterator_v（C++20）才能触发 - 若你用自定义迭代器包装 trivial 类型，大概率不会被识别，仍走泛型 loop
- 调试模式（
_GLIBCXX_DEBUG）下 GCC 可能禁用该优化以保安全检查
容易踩的坑：看似 trivial 实则不是
这些类型常被误认为 trivially copyable，但实际不是：
- 含
std::string、std::vector成员的类（即使其他成员都是 POD）→ 因为它们的拷贝需调用构造函数 - 有虚函数或虚基类的类 →
std::is_polymorphic_v<T>为true时必然非 trivially copyable - 含引用成员或 const 成员的类 → 不可默认赋值，破坏 triviality
- 移动构造/赋值被显式删除，但拷贝未被删除 → 仍可能 trivially copyable；但若拷贝被
= delete，则一定不是
最稳妥的检查方式是：
static_assert(std::is_trivially_copyable_v<MyType>, "MyType must be trivially copyable for fast memcpy path");
放在关键路径头文件里，CI 失败比运行时崩溃好定位得多。
真正难的不是判断是否 trivially copyable，而是确认你手动 memcpy 的那块内存，既没被其它线程同时读写，也没有 RAII 资源需要析构——这点没人帮你检查。
