编译器能“看穿”虚函数调用需满足三个前提：确切动态类型可确定、该类型无法被进一步派生覆盖目标函数、且编译器具备足够信任度与优化层级。
编译器能“看穿”虚函数调用的三个前提
当编译器在某个调用点能确定指针或引用所指向对象的**确切动态类型**，且该类型**无法被进一步派生覆盖目标函数**时，它就可能把 virtual 调用优化成直接调用（甚至内联）。这不是玄学，而是基于静态分析的确定性判断。
final 是最简单有效的触发条件
给派生类加 final 关键字后，编译器立刻知道这个类不会再有子类。如果此时你用该类型的指针/引用调用虚函数，或者通过基类指针但编译器能推导出实际类型唯一，调用就可能被去虚化。
-
struct B final : A { void foo() override; };→B*或B&调用foo()几乎必然被直接调用 - 即使写成
A* p = new B;，在-O2及以上且无跨编译单元干扰时，p->foo()也常被优化为B::foo()直接调用 - 不加
final时，哪怕当前项目里没定义任何B的子类，编译器也不能假设未来不会加——它必须为多态留后路
局部作用域 + 明确构造方式是常见突破口
编译器对栈上对象、返回值、临时对象的类型掌握得最清楚。只要没发生逃逸（比如没把地址传给外部函数），很多虚调用会被“折叠”掉。
-
Derived d; d.foo();→ 直接调用Derived::foo()，完全不查虚表 -
auto d = make_derived(); d.foo();（make_derived()返回Derived值）→ 同样直接调用 - 但
Base* p = &d;再调p->foo()就不一定了：取决于编译器能否证明p没被别名修改、没传入未知函数等
链接时优化（LTO）和 -fstrict-vtable-pointers 能帮编译器“信得过”
默认情况下，编译器不敢假设对象的 vptr 在生命周期内不变——因为存在像 *(uintptr_t*)obj = ... 这种 UB 操作可能篡改它。启用 -fstrict-vtable-pointers 后，编译器就敢把多次虚调用中重复的虚表查找合并，甚至结合 LTO 推断出最终类型。
-
-flto -fstrict-vtable-pointers组合在大型项目中常让原本无法优化的虚调用“突然变快” - 但注意：这个 flag 要求你代码里**绝不能手动修改 vptr**（比如通过
reinterpret_cast强制覆盖），否则行为未定义 - Clang 的
-fwhole-program-vtables更激进，它假设整个程序的虚表结构是封闭的，适合嵌入式或单体构建场景
真正容易被忽略的是：哪怕满足所有条件，如果函数体本身太大、含复杂分支、或调用链太深，编译器也可能放弃内联。虚函数能否被直接调用，本质是“类型确定性 + 编译器信任度 + 优化层级”的三重叠加，不是加个 final 就万事大吉。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
