静态绑定在编译期完成，依据参数类型通过函数重载或模板推导确定调用版本，不依赖对象实际类型，不查虚表。
静态绑定发生在编译期，靠函数重载和模板推导
编译器在看到 func(x) 这种调用时，如果 func 是普通函数、函数重载或模板实例化，它会根据参数类型直接确定调用哪个版本——这个过程不依赖对象实际类型，也不查虚表。比如：
void print(int) { cout << "int"; }
void print(double) { cout << "double"; }
print(42); // 绑定到 int 版本，编译期决定
这种绑定快得几乎没开销：就是个跳转地址写死在指令里。但代价是灵活性差——你不能在运行时换行为。
常见错误是误以为重载能“覆盖”基类虚函数：
- 如果基类有
virtual void draw()，子类写了void draw(int)，这不算重写，只是新增重载，调用时仍走虚函数机制（如果用基类指针调用无参版），容易漏掉预期的多态效果。
动态绑定靠虚函数表，运行时查表跳转
只要用了 virtual，哪怕只在基类声明一次，所有继承链上的同签名函数都参与动态绑定。调用时，编译器生成的代码会先取对象首字节的 vptr，再按偏移查 vtable，最后跳转到实际函数地址。
立即学习“C++免费学习笔记（深入）”；
Base* p = new Derived(); p->draw(); // 编译器不决定调谁，运行时看 p 指向的对象的 vtable
性能影响很实在：一次额外内存访问（vptr → vtable → 函数地址），现代 CPU 能缓存 vtable，但若对象分散在堆上、vtable 频繁换页，就可能触发 cache miss。比起静态绑定，延迟多 1–3 个周期，多数场景可忽略，但在 tight loop 里反复调用虚函数（比如图形渲染每像素一次 draw），差异会累积。
容易踩的坑：
- 构造/析构函数里调虚函数：此时 vptr 指向当前正在构造/析构的类的 vtable，不会调派生类的重写版本
- 把虚函数声明成
inline：编译器通常忽略 inline 提示，因为无法内联（地址不确定） - 忘记基类析构函数是 virtual：
delete base_ptr可能只调基类析构，子类资源泄漏
override 和 final 不改变绑定时机，但防错明显
override 只是编译期检查：确保你写的函数确实在基类中被声明为 virtual 且签名匹配。不加它，拼错函数名或参数类型（比如把 const 漏了），编译器会静默当成新函数，导致动态绑定失效——看着像多态，实则调的是基类版本。
final 的作用更务实：告诉编译器“这个虚函数不允许再被重写”，于是某些优化器可以大胆假设调用目标固定，甚至在特定条件下退化为静态绑定（虽然标准不保证，但 GCC/Clang 在 -O2 下对 final 类的虚调用有时会去虚化）。
使用场景很明确：
- 多层继承中，中间类想封住某个接口演化路径，用
final - 协作开发时，子类作者不确定是否重写了关键虚函数，加
override让编译器立刻报错
性能敏感代码里，优先考虑静态替代方案
不是所有多态都需要虚函数。比如策略模式中，如果策略数量固定、生命周期长，用 std::variant + std::visit 或模板参数传入，就能把分发逻辑拉回编译期：
template<typename Strategy>
class Processor {
void run() { strategy_.execute(); } // 静态绑定
};
或者用函数指针数组代替虚表（手动管理），适合嵌入式等极端场景。但代价是失去类型安全和自动内存管理。
真正难处理的是那种“运行时才知道要创建哪种对象”的情况（比如插件系统、配置驱动模块），这时虚函数仍是合理选择——别为了省几个周期提前 micro-optimize，先确认 profile 数据真显示它是瓶颈。
虚函数调用本身不慢，慢的是你让它承载了不该承载的东西：比如在虚函数里做字符串解析、磁盘 I/O、或递归调用自身。绑定机制只是入口，瓶口之后才是真瓶颈。
虚表指针的位置、vtable 的布局、RTTI 是否开启，这些细节不同编译器略有差异，但只要你没用 reinterpret_cast 破坏对象布局，或者跨 DLL 边界传递虚基类对象，就不用操心。真正容易出问题的，永远是语义理解偏差，而不是机制本身。
