虚函数表在编译期确定布局，是只读段中的静态函数指针表；vptr作为隐式成员存在于对象中，构造时才初始化，决定多态行为时机。
虚函数表在编译期就确定了布局
虚函数表本身不是运行时“创建”的，而是编译器在编译阶段为每个含虚函数的类生成一张静态的函数指针表。这张表的内容（哪些函数地址填在哪）由类定义和继承关系决定，不依赖具体对象实例。
常见错误现象：sizeof(Base) 比预期大 4 或 8 字节（取决于指针大小），却误以为是“对象构造时才加进去的”——其实是编译器早已把 vptr（虚表指针）作为隐式成员塞进了对象内存布局里。
- 只要类中声明了
virtual函数（包括析构函数），编译器就会为其生成 vtable - 派生类若重写虚函数，vtable 中对应槽位会被替换成派生类版本的地址；若新增虚函数，则扩展 vtable
- 多重继承下可能有多个
vptr，但每个 vtable 仍是编译期固定结构
对象构造时才初始化 vptr，不是 vtable
vtable 是只读数据段里的常量，而每个对象的 vptr 是在构造函数执行过程中被赋值的。这个时机非常关键：基类构造函数运行时，vptr 指向基类 vtable；派生类构造函数体开始前，vptr 才被更新为指向派生类 vtable。
使用场景：在构造函数里调用虚函数，实际调用的是当前正在构造的那个类的版本，而不是最终派生类的重写版——因为此时 vptr 还没切换过去。
立即学习“C++免费学习笔记（深入）”；
- 基类构造函数中调用
virtual func()→ 调用基类版本，哪怕派生类重写了它 - 派生类构造函数体第一行之后，
vptr已更新，但此时成员变量可能尚未初始化 - 禁止在构造/析构函数中做多态分发逻辑，容易踩到“半成品对象”陷阱
虚函数表地址可被直接读取，但高度依赖 ABI
你可以通过对象地址偏移拿到 vptr，再解引用得到 vtable 首地址，甚至调用其中函数——但这属于未定义行为（UB）的边缘操作，仅用于调试或逆向理解。
参数差异：不同编译器（GCC / MSVC / Clang）对 vtable 布局、vptr 位置、RTTI 存储方式都不同；同一编译器不同优化等级也可能影响内联后是否还保留虚调用。
-
*(void**)obj_ptr可能拿到vptr，但偏移量不一定是 0（尤其有虚继承时） - 访问
vtable[0]不一定对应第一个声明的虚函数（编译器可能重排，尤其涉及虚析构时） - 开启
-fno-rtti后，某些编译器会简化 vtable 结构，但虚调用仍有效
动态库中跨 SO 的虚函数调用要小心符号可见性
如果基类定义在动态库 A 中，派生类实现在动态库 B 中，且虚函数未显式导出，那么 B 中的重写函数可能无法被 A 中的虚调用正确绑定——vtable 初始化时找不到符号，导致崩溃或跳转到错误地址。
性能影响：虚调用本身只是一次指针解引用 + 间接跳转，现代 CPU 分支预测很准，开销远小于 cache miss；真正慢的是破坏内联和阻碍编译器优化。
- Linux 下需确保虚函数声明带
__attribute__((visibility("default"))) - Windows DLL 需用
__declspec(dllexport)导出基类和所有虚函数 - 模板类不生成 vtable，所以
std::vector没有虚函数开销
vptr 在构造链中的切换节奏，以及跨模块时符号能不能被 vtable 正确引用到。 
