memcpy直接复制二进制字节，跳过构造/析构，仅适用于trivially copyable类型；含string/vector/虚函数等非平凡类型使用会导致双重释放、越界、资源泄漏或vptr错乱。
memcpy会跳过构造/析构，直接复制二进制字节
这是最根本的问题。memcpy根本不认识C++对象——它只认内存地址和字节数。调用memcpy(&dst, &src, sizeof(T))时，编译器不会插入任何构造函数、拷贝构造函数或析构函数调用，连成员变量的类型语义都一概无视。
常见错误现象：
- 含
std::string的类被memcpy后，两个对象共享同一块堆内存指针，析构时触发双重释放 - 含
std::vector的对象复制后，data_指针被原样搬运，但容量/大小信息未同步更新，后续push_back可能越界或崩溃 - 自定义资源管理类（如文件句柄、GPU显存指针）完全丢失清理逻辑，造成资源泄漏
虚函数表（vtable）指针会被错误覆盖
C++对象若含虚函数，编译器会在对象起始位置隐式插入一个vptr，指向该类型的虚函数表。memcpy会把源对象的vptr值原封不动写入目标对象内存，但目标对象原本就该有自己的vptr——这相当于强行篡改了它的动态类型绑定。
使用场景举例：
立即学习“C++免费学习笔记（深入）”；
-
class Base { virtual void f(); };和class Derived : public Base { void f() override; }; - 用
memcpy把Derived对象复制到Base对象上 → 目标对象vptr指向Derived的虚表，但静态类型是Base，调用f()时行为不可预测 - 若源对象生命周期结束，其虚表可能被卸载，后续调用直接崩溃
只有 trivially copyable 类型才勉强安全
不是“能编译通过就能用”，而是必须满足严格条件：std::is_trivially_copyable_v<t></t>为true。这意味着：
- 类不能有虚函数、虚基类
- 不能有用户定义的拷贝/移动/赋值/析构函数
- 所有非静态成员和基类都必须是平凡可拷贝的
- 例如：
struct { int x; double y; char buf[16]; };可以；struct { std::string s; };绝对不行
验证方式必须写死在编译期：static_assert(std::is_trivially_copyable_v<mystruct>, "unsafe for memcpy");</mystruct>
std::copy 或赋值运算符才是正确选择
std::copy本质是循环调用迭代器所指元素的拷贝构造或赋值运算符，它尊重C++对象语义；而内置赋值=在类未禁用时默认调用拷贝赋值运算符。
实操建议：
- 数组或容器元素拷贝：优先用
std::copy(src.begin(), src.end(), dst.begin())，而非memcpy - 单个对象拷贝：直接写
dst = src;或T dst = src;，让编译器走正确的构造路径 - 性能敏感场景？先确认是否真瓶颈——现代编译器对
std::copy和简单赋值常做优化，且安全成本远低于调试未定义行为的时间
最容易被忽略的一点：即使类当前没有虚函数、没有成员对象，只要未来有人加了一个std::string成员或virtual函数，memcpy就会立刻从“看似工作”变成“随机崩溃”。这种脆弱性没法靠测试覆盖，只能靠编码习惯堵死。
