std::memcpy仅按字节复制，仅对平凡可复制类型安全；std::copy调用赋值运算符，要求目标已构造；std::uninitialized_copy用于原始内存的批量构造拷贝，三者语义与适用场景截然不同。
std::memcpy 直接搬内存，完全跳过构造函数
它不管对象类型，只按字节把源地址内容原样复制到目标地址。对 POD 类型（比如 int、struct 里只有 public 成员且无虚函数/用户定义构造函数）是安全的；但一旦对象有非平凡构造函数、析构函数、虚表指针或引用成员，std::memcpy 就会绕过所有语义逻辑，导致未定义行为。
常见错误现象：std::memcpy 后调用 obj.method() 崩溃、访问已释放内存、虚函数调用跳转到随机地址——本质是没初始化虚表指针，或没执行成员对象的构造函数。
- 不检查类型是否可平凡复制（
std::is_trivially_copyable_v<t></t>必须为true才能用） - 不处理对齐问题：若源/目标地址未按
T对齐，某些平台会触发硬件异常 - 不更新 RAII 资源状态：比如拷贝一个含
std::unique_ptr的类，目标对象的指针字段只是“影子副本”，两个对象指向同一块内存，析构时 double-free
std::copy 调用赋值运算符，尊重对象生命周期
std::copy 是泛型算法，对每个元素调用 operator=（或移动赋值，若适用）。这意味着它会触发目标对象的赋值逻辑：已有对象被重新赋值，而非重建；如果目标内存尚未构造对象，则行为未定义——你得先确保目标位置已调用构造函数（比如用 std::uninitialized_copy 或 placement new）。
使用场景：容器间拷贝、重用已分配内存、配合 std::vector::data() 更新连续对象数组。
立即学习“C++免费学习笔记（深入）”；
- 对非 trivial 类型必须保证目标内存已构造好对象（否则
operator=作用在未初始化内存上） - 若源/目标范围重叠，
std::copy不保证正确性；该用std::copy_backward或std::memmove - 性能差异明显：
std::copy可能触发多次虚函数调用或深拷贝，而std::memcpy是纯内存带宽操作
想安全地批量构造+拷贝？用 std::uninitialized_copy
当你有一块原始内存（比如 malloc 出来的、或 std::vector<char></char> 底层），需要把对象序列“放进去”并调用构造函数时，std::uninitialized_copy 是唯一正解。它对每个位置调用 placement new + 拷贝构造函数，既不依赖 operator=，也不跳过构造逻辑。
错误用法示例：std::memcpy(dst, src, n * sizeof(T)) 替代 std::uninitialized_copy —— 对 std::string 这种类型，结果是 dst 内存里全是未初始化的 std::string 对象，后续任何访问都 UB。
- 目标迭代器必须指向未构造内存（不能是已存在对象的地址）
- 失败时会自动析构已构造的部分（强异常安全）
- 和
std::copy不同，它不要求目标类型可赋值，只要求可构造
编译器不会帮你拦住 memcpy 错用
即使你对 std::string 或带虚函数的类用了 std::memcpy，GCC/Clang 默认不报错，运行时才崩。启用 -fsanitize=undefined 可捕获部分问题（如对 non-trivial 类型 memcpy），但不是万能的。
真正可靠的防护是静态断言：
static_assert(std::is_trivially_copyable_v<MyType>, "MyType is not safe to memcpy");
或者更进一步，用 std::is_trivially_constructible_v 和 std::is_trivially_destructible_v 组合判断。
容易被忽略的是：继承关系下，基类可能 trivial，派生类却因新增虚函数或成员而不满足条件——别只看顶层类型声明。
