构造函数中调用虚函数不安全，因vptr分阶段更新：基类构造时指向基类虚表，派生类构造后才切换，此时虚调用静态绑定到当前类版本，无法实现多态。
直接说结论：构造函数里不能安全调用虚函数，这不是写法问题，而是语言机制决定的未定义行为风险点。
C++ 在对象构造过程中，虚函数表指针（vptr）是分阶段更新的。你调用一个虚函数时，实际走的是当前 vptr 所指的虚函数表 —— 而这个表在基类构造函数执行时指向基类，在派生类构造函数执行后才切换为派生类。中间没有“过渡态”，也没有运行时多态保障。
为什么 Base::Base() 里调用 virtualFunction() 不会进 Derived::virtualFunction()
Base::Base() 里调用 virtualFunction() 不会进 Derived::virtualFunction()
- 构造从基类开始：
Base的构造函数执行时，Derived对象还没开始构造，其成员、重写的虚函数都尚未就绪。 - 此时
vptr指向Base的虚函数表，哪怕你传入的是Derived类型的对象（如Derived d;），在Base构造阶段，它“逻辑上”还只是个Base。 - 编译器对构造函数内的虚函数调用做静态绑定：直接绑定到当前正在构造的类的版本，不查虚表。
常见错误现象：
- 期望输出
Derived::virtualFunction()，实际输出Base::virtualFunction() - 若
Base::virtualFunction()是纯虚函数且未提供定义，程序链接失败或运行时崩溃（Pure virtual function called）
替代方案：用初始化列表 + 非虚接口组合规避
把需要多态行为的逻辑，从构造函数体内“移出来”，改用显式、可控的方式初始化：
立即学习“C++免费学习笔记（深入）”；
- 使用工厂函数或静态
create()方法封装构造+初始化 - 把虚函数调用推迟到对象完全构造之后（例如首次
init()调用） - 利用初始化列表传递已知值，避免在构造函数体中依赖虚函数结果
class Base {
public:
Base(int value) : m_value(computeInitialValue(value)) {} // 非虚计算
protected:
virtual int computeInitialValue(int v) { return v * 2; }
private:
int m_value;
};
<p>class Derived : public Base {
public:
Derived(int value) : Base(value) {} // 不在 Base() 内调虚函数
protected:
int computeInitialValue(int v) override { return v * 3; } // 安全：只在 Base 初始化列表中被 Base::Base() 调用
};注意：
-
computeInitialValue()在Base构造函数体外、初始化列表中被调用，此时this指针类型仍是Base*，仍走Base版本 - 所以更稳妥的做法是：让
computeInitialValue非虚，或通过参数/策略对象注入行为，而非靠继承多态
误用 memcpy 或手动操作 vptr 的后果
memcpy 或手动操作 vptr 的后果有些开发者试图绕过限制，比如在构造函数里用 memcpy 覆盖对象内存、强行修改 vptr 地址：
- 这属于未定义行为（UB）
- 编译器可能优化掉你的操作，或在不同平台/标准库下表现不一致
-
vptr位置由 ABI 约定（通常在对象起始），但不是公开接口；手动写入极易越界或破坏对齐 - 即使“暂时成功”，后续任何虚函数调用、
dynamic_cast、异常栈展开都可能崩溃
性能与兼容性影响：
- 无性能收益，只有稳定性代价
- GCC / Clang / MSVC 均不保证这种操作的可移植性
- C++ 标准明确禁止访问对象的
vptr（它是实现细节）
关键点其实就一个：构造函数的职责是“让对象达到可用状态”，而不是“让对象表现出完整多态行为”。
虚函数的本质是运行时动态分发，而构造过程本身是编译时确定的静态流程。两者天然错位。真正容易被忽略的，不是“怎么调”，而是“为什么连‘看起来能调’都是陷阱”——因为 vptr 的切换时机和对象生命周期阶段强绑定，没法插队，也没法协商。
