虚函数调用需查vtable因编译期无法确定具体实现，运行时通过对象的_vptr查找对应函数地址；vtable在编译期生成，含该类所有虚函数地址（含重写基类函数），纯虚函数存占位地址；虚析构函数必须声明为virtual以防资源泄漏；override和final不改变vtable结构但增强类型安全与优化可能。
虚函数调用为什么需要查表
因为编译期无法确定最终调用哪个函数实现——基类指针或引用指向的对象类型，只有运行时才知道。C++ 选择用 vtable（虚函数表）来承载这种延迟绑定：每个含虚函数的类生成一张函数指针数组，对象头部隐式存储一个指向该表的指针（_vptr）。
常见错误现象：sizeof(Base) 比预期大 4 或 8 字节（取决于平台），就是被悄悄加了 _vptr；若类没虚函数，_vptr 就不会存在。
- 虚函数表在编译期生成，内容是该类所有虚函数的地址（包括从基类继承并被重写的）
- 派生类的
vtable会复制基类虚函数条目，再用自己版本覆盖被重写的项 - 纯虚函数在表中存的是类似
__cxa_pure_virtual的占位地址，触发调用时直接 abort
如何观察 vtable 内容（GCC/Clang）
不能靠源码直接看到 vtable，但可以用编译器工具链反推。例如 GCC 提供 -fdump-class-hierarchy 选项，生成人类可读的类布局报告：
g++ -fdump-class-hierarchy example.cpp
输出里会明确列出每个类的 vtable 地址、虚函数顺序、以及各虚函数在表中的偏移。注意：不同编译器（MSVC vs GCC）、不同标准（C++11 vs C++17）、甚至是否开启优化（-O2）都可能影响 vtable 的具体组织方式。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 虚函数在表中顺序 = 声明顺序（不是定义顺序），且与基类中声明位置强相关
- 添加新虚函数到类中间，会导致整个
vtable偏移变化，ABI 不兼容 - 静态成员函数、内联函数、构造函数永远不会进
vtable
虚析构函数为什么必须写 virtual
否则通过基类指针删除派生类对象时，只会调用基类析构函数，派生类部分内存泄漏、资源不释放——这不是“没调用”，而是根本没走虚调用路径，连 vtable 都没查。
- 只要类设计为多态基类（即预期被继承+通过基类指针管理生命周期），析构函数就必须是
virtual -
virtual ~Base() = default;是安全且推荐的写法；写空实现{}也行，但不如= default清晰表达意图 - 如果类不含虚函数，又没被设计为基类，加
virtual析构反而引入不必要的_vptr开销
override 和 final 怎么影响 vtable 生成
它们不改变 vtable 结构本身，但能帮编译器提前发现错误，避免意外覆盖失败导致调用错函数。比如拼错函数名、参数 const 修饰不一致、返回类型协变违规等，都会让 override 编译失败。
-
override强制要求该函数必须重写基类虚函数，否则报错；它不新增虚函数，也不修改vtable条目位置 -
final阻止后续派生类重写该虚函数，对应vtable中该槽位在派生类中被锁定，不能再被替换 - 滥用
final会让类失去扩展性；但对性能敏感的热路径，final可能帮助编译器 devirtualize（转为直接调用）
虚函数机制本质是用空间换时间：每个对象多几个字节，每次调用多一次指针解引用+跳转。真正难的不是理解 vtable，而是判断什么时候不该用它——比如小对象、固定类型集合、性能关键循环里，std::variant 或模板策略可能更合适。
