memcpy 复制含虚函数对象会破坏完整性，因不调用构造函数、不处理虚继承偏移等，导致虚表错位和未定义行为；仅 pod 类型安全，含虚函数者恒非 trivially copyable，必须使用拷贝构造函数或 clone 接口。
memcpy 会直接复制虚表指针，但破坏对象完整性
虚函数对象的内存布局里，vptr（虚表指针）通常在对象起始位置，memcpy确实能把它原样拷过去。但这只是表象——真正的问题在于：它不调用构造函数，不初始化基类子对象，不处理虚继承偏移，也不更新派生类中可能存在的其他隐藏状态（比如 RTTI 相关字段）。结果就是，你得到一块“看起来像”原对象的内存，但它的虚表指向可能失效，或者指向了错误的虚表（尤其在多态继承链中）。
常见错误现象：segmentation fault 或调用到完全无关的函数体；调试时发现 this 指针地址正常，但 dynamic_cast 失败、typeid 返回基类类型；在启用 ASan 的环境下触发 heap-use-after-free 类似误报（实际是虚表错位导致的非法跳转）。
- 仅当对象是 POD 类型（无虚函数、无非静态成员、无虚基类等）时，
memcpy才安全 - 含虚函数的类自动失去 POD 资格，哪怕只有一个
virtual析构函数也不行 - 即使你确认当前对象没虚继承、没虚基类，也不能保证未来子类扩展后仍安全
替代方案：必须走构造函数路径
要复制一个含虚函数的对象，唯一可靠的方式是调用其拷贝构造函数——这确保了虚表正确设置、基类子对象被初始化、虚继承偏移被修正。如果类没定义拷贝构造函数，编译器生成的默认版本也满足要求（前提是所有成员都可拷贝）。
使用场景：深拷贝容器中的多态对象、序列化反序列化后重建对象、实现 clone 接口。
立即学习“C++免费学习笔记（深入）”；
- 优先声明并定义
clone()成员函数，返回std::unique_ptr<base>，内部调用new Derived(*this) - 避免裸指针 +
memcpy组合：比如char buf[sizeof(Derived)]; memcpy(buf, &obj, sizeof(obj)); Derived* p = new(buf) Derived;—— 这是 placement new + memcpy 的危险组合，vptr可能被后续构造函数覆盖两次或未覆盖 - 若需字节级拷贝（如网络传输），应显式序列化：把虚函数逻辑剥离，只传数据成员，接收端再用对应类型重建
容易被忽略的隐性陷阱：编译器优化与 ABI 差异
不同编译器（GCC / Clang / MSVC）对虚表布局、vptr 插入位置、虚继承调整项的实现并不一致。同一段 memcpy 代码，在 GCC 下看似工作，在 Clang 下可能立即崩溃；开启 -O2 后，编译器甚至可能把部分虚调用内联掉，掩盖问题，但换一个优化级别又复现。
性能影响：有人误以为 memcpy 比构造函数快——其实现代编译器对 trivially copyable 类型的拷贝构造会自动优化为 memcpy，而对非 trivial 类型，强制 memcpy 不仅没收益，还引入 undefined behavior。
- 检查是否 trivially copyable：用
std::is_trivially_copyable_v<t></t>编译期断言，含虚函数的类恒为false - 不要依赖
sizeof(Base) == sizeof(Derived)做 memcpy：虚继承、对齐填充、编译器 ABI 都会让大小不等 - ASan/UBSan 很难捕获这类问题，因为虚表跳转本身不触发内存越界，只能靠静态分析工具（如 clang++ -fsanitize=undefined）或人工 code review
最危险的“看起来能跑通”的情况
单继承、无虚基类、无数据成员、只有一层虚函数的类，在特定编译器+标准库组合下，memcpy 后调用虚函数偶尔真能成功。这不是安全，是巧合。一旦加入一个 std::string 成员、或升级 STL 版本、或跨 shared library 边界传递对象，就会崩。
这种侥幸心理比直接报错更麻烦：它让问题潜伏在测试覆盖率低的分支里，上线后在客户环境随机触发。
- 别用 “我试过，它没崩” 判断安全性，要用语言标准和类型属性判断
- 虚函数存在即意味着对象生命周期必须由构造/析构函数管理，绕过它们就是 UB
- 如果真需要高性能拷贝，重构为不含虚函数的数据结构 + 独立策略类，而非硬啃 memcpy
事情说清了就结束。
