对含虚函数的类调用memset会直接覆盖vptr导致虚函数调用时解引用空指针而崩溃；判断能否安全使用需满足trivially default constructible，可用std::is_trivially_default_constructible_v检测；应改用{}初始化、构造函数或std::fill_n等类型安全方式。
对含虚函数的类调用memset会直接覆盖vptr
虚函数表指针（vptr）通常位于对象内存布局的最开头，memset(&obj, 0, sizeof(obj)) 会把这块内存全部置零，vptr 就变成空指针。后续任何虚函数调用（如 obj.func() 或通过基类指针调用）都会因解引用空指针而崩溃——不是延迟报错，是立即未定义行为。
这种错误在调试时往往表现为“访问冲突”或“EXCEPTION_ACCESS_VIOLATION”，且只在虚函数被调用时触发，容易误判为逻辑问题而非初始化错误。
判断一个类型能否安全用memset：看是否为trivially default constructible
不是“有没有写构造函数”这么简单，而是编译器是否认定该类型可平凡默认构造。C++11 起可用 std::is_trivially_default_constructible_v 编译期检测：
struct Plain { int x; };
class WithVirt { virtual void f() {} };
static_assert(std::is_trivially_default_constructible_v<plain>); // ✅ 通过
static_assert(std::is_trivially_default_constructible_v<withvirt>); // ❌ 失败
</withvirt></plain>
- 只要类声明了虚函数、虚析构、虚继承，或含有非平凡成员（如
std::string），就一定不满足 - 即使你没写构造函数，编译器合成的构造函数若涉及虚表初始化，它就不是 trivial 的
- POD 类型在 C++11 后已拆分为
trivial+standard-layout两个独立条件，缺一不可
替代方案：用{}初始化、构造函数或std::fill_n
清零需求本质是“默认初始化”，应交由语言语义处理，而非手动字节操作：
- 结构体/类定义时加默认成员初始化：
int x{0}; std::string s{};，之后直接T obj;即可 - 显式值初始化：
T obj{};（注意不是T obj;，后者对内置类型是未初始化） - 对数组用
std::fill_n(arr, N, T{});，类型安全，且对std::string等会调用其默认构造 - 若必须批量初始化堆内存（如
new T[N]），优先用new T[N]{};（带括号的值初始化），而非memset
Windows 下 ZeroMemory 宏等价于 memset，同样危险
ZeroMemory 是 Windows SDK 中的宏，展开后就是 memset(ptr, 0, size)，和 memset 没有任何语义区别。它不能规避虚表破坏问题，也不能绕过 STL 成员的内部状态约束。
很多旧代码里混用 ZeroMemory 和类对象，只因它名字里有 “Zero”，看起来“更安全”——这是典型认知陷阱。真正安全的初始化，永远来自类型的构造函数语义，而不是字节填充。
虚表破坏不是小概率事件，它是确定性未定义行为；只要用了 memset 初始化含虚函数的对象，崩溃只是时间问题，而且往往发生在上线后难以复现的路径上。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
