final 不影响函数调用，只禁止派生类重写；它不改变虚函数的动态分发机制，仍正常走虚表，但为编译器提供优化线索，可能实现内联或省略虚查。
能正常调用，和是否加 final 完全无关
加 final 只影响“能不能被派生类重写”，不改变函数本身的可调用性、访问权限或运行行为。只要调用方式合法（对象存在、有访问权限、参数匹配），final 修饰的虚函数和普通虚函数一样，该走虚表就走虚表，该动态分发就动态分发。
为什么 final 不影响调用逻辑
final 是编译期约束，只参与继承/重写检查，不生成额外运行时开销，也不修改虚函数表结构：
- 虚函数表（vtable）照常生成，
final函数地址仍填在对应槽位 - 通过基类指针或引用调用时，仍按常规虚调用流程：查
vptr→ 查 vtable → 跳转执行 - 直接通过对象调用（非指针/引用）时，若函数非内联，仍可能走虚调用；但现代编译器在确定类型时可能优化掉虚表查询 —— 这和
final无关，而是类型可见性带来的优化机会
final 修饰后编译器报错的典型场景
错误不是发生在“调用”，而是在“试图重写”或“试图继承”时：
-
class Base { virtual void foo() final; };→class Derived : public Base { void foo() override; };报错：error: cannot override a function marked 'final' -
class Base final { ... };→class Derived : public Base { ... };报错：error: cannot derive from 'final' base 'Base' - 误以为
final会让函数变成“静态绑定”，于是手动去掉virtual：这是错的 ——final必须修饰虚函数，不能用于非虚函数
一个容易被忽略的性能细节
虽然 final 本身不改变调用路径，但它**给编译器提供了更强的类型确定性**：
- 当编译器能推断出某个
final函数的最终实现（例如通过static_cast到 final 类型，或局部对象直接调用），它可能跳过虚表查询，甚至内联该函数 - 对比非
final虚函数：即使当前没派生类，编译器也不能假设未来不会被继承，通常不敢内联（除非 LTO + 全程序分析） - 所以
final的实际价值之一，是让虚函数在特定上下文中获得接近非虚函数的性能
真正卡住调用的从来不是 final，而是虚函数本身的语义限制：比如对象已析构、指针为空、或调用发生在构造/析构函数中且虚函数被纯虚化 —— 这些问题跟 final 没半点关系。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
