override用于标记虚函数重写并强制编译器检查签名匹配，final用于禁止虚函数被进一步重写或类被继承；二者可共存且必须写作override final。
override 用来标记虚函数重写，编译器会检查签名是否匹配
如果你在派生类里写了一个函数，本意是重写基类的虚函数，但参数类型、const 修饰、返回类型或 noexcept 声明稍有不一致，编译器不会报错——它会悄悄创建一个新函数（重载），而不是重写。这容易引发逻辑错误，比如 std::vector::push_back 被误写成非 const 版却没生效。
加上 override 后，编译器强制校验：该函数必须存在对应的基类虚函数声明，且签名（包括 const、noexcept、参数类型、返回类型协变规则）完全兼容。不满足就直接报错。
常见踩坑点：
- 基类函数没声明为
virtual，子类加override会编译失败 - 基类函数是
const，子类函数漏掉const→ 不匹配，override触发错误 - 返回类型不是协变（如基类返回
Base*，子类返回Derived*是允许的；但返回int和double就不行）
class Base {
public:
virtual void foo() const noexcept { }
};
class Derived : public Base {
public:
void foo() const noexcept override { } // ✅ 正确
void foo() override { } // ❌ 缺少 const，编译失败
};
final 阻止虚函数被进一步重写，或阻止类被继承
final 是个“终止符”，用在两个位置语义不同，但目标一致：明确表达“到此为止”。
立即学习“C++免费学习笔记（深入）”；
用在函数声明末尾（在 override 或 ; 前），表示这个虚函数不能再被派生类重写；用在类名后（跟在 class Derived final : ...），表示这个类不能作为基类被继承。
典型使用场景：
- 关键算法已做最优实现（如加密/序列化核心逻辑），不希望子类意外改变行为
- 防止抽象基类被不当继承（比如你只提供
std::unique_ptr<base>接口，但不希望用户继承Base） - 配合
override形成完整覆盖链：基类virtual→ 中间层override→ 最终层override final
class Base {
public:
virtual void bar() = 0;
};
class Middle : public Base {
public:
void bar() override final { } // ✅ Middle::bar 不可再被重写
};
class Last : public Middle {
public:
void bar() override { } // ❌ 编译错误：Middle::bar 是 final
};
override 和 final 可以共存，但顺序固定
当你要同时表明“这是重写”和“不允许再重写”，语法上必须写成 override final，顺序不能颠倒；final override 是非法的。
这个顺序不是随意定的：override 描述的是“我与基类的关系”，final 描述的是“我对派生类的约束”，所以前者在前更符合逻辑流向。
其他注意事项：
-
final不能用于非虚函数（否则无意义，编译器会报错） - 类声明为
final后，其所有虚函数自动成为final（即使没显式写），但显式标注仍推荐，提高可读性 - 如果基类函数是
final，子类尝试override会失败；反过来，如果子类用了final，不影响基类函数本身是否可被重写
不加 override 的实际风险比想象中高
很多老代码或 C++11 之前写的项目没用 override，靠人工核对函数签名。但现代项目常涉及模板、SFINAE、auto 返回类型推导，很容易出现“看似重写实则重载”的情况。
例如：基类有 virtual std::string getName() const，子类写了 std::string getName()（漏 const）→ 它不是虚函数重写，而是独立函数；调用 ptr->getName() 时，若 ptr 是基类指针，实际执行的仍是基类版本。
这种 bug 往往只在运行时暴露，且难以定位。而 override 是零成本的编译期防护，开启后几乎不增加构建时间，但能提前拦截大量低级错误。
真正难处理的，其实是那些跨模块、跨版本的虚函数接口变更——比如基类头文件更新了函数签名，但链接的旧版动态库仍按老签名分发 vtable。这时 override 无法起作用，得靠 ABI 兼容策略或版本号管理。
