override用于显式声明重写虚函数，编译器严格检查签名匹配；final用于禁止类继承或虚函数重写，增强安全性与可读性。
final 和 override 是 C++11 引入的两个上下文关键字，它们不改变程序逻辑，但能显著提升代码的可读性、可维护性和安全性——尤其在面向对象的继承体系中。
override：明确表达“我要重写虚函数”
当你在派生类中定义一个函数，意图重写基类的虚函数时，如果函数签名（参数类型、const 修饰、引用限定符等）稍有偏差，编译器可能不会报错，而是悄悄创建一个**新函数**（而非重写），导致运行时调用错误版本，引发难以排查的逻辑 bug。
加上 override 后，编译器会严格检查：该函数是否确实重写了基类中的某个虚函数。如果不匹配（比如参数少了一个 const、返回类型不协变、或基类根本没有对应虚函数），编译直接失败。
- 写法：放在函数声明末尾，分号前，例如
void func() override; - 只用于成员函数，且必须是虚函数（隐式或显式）
- 不是修饰符，不参与类型系统；仅用于编译期检查
final：禁止进一步继承或重写
final 有两种使用场景，都起到“封顶”作用：
立即学习“C++免费学习笔记（深入）”；
- 加在 类名后（如
class Widget final { ... };），表示该类不能被继承。任何尝试从它派生的代码都会编译失败。 - 加在 虚函数声明末尾（如
virtual void draw() final;），表示该虚函数在当前类中是最终实现，其派生类不可再重写它。
这不仅防止意外误继承/误重写，也向其他开发者清晰传达设计意图：“此处已定型，勿动”。对编译器而言，final 还可能开启优化（如去虚化调用）。
为什么它们提升可读性与安全性？
没有它们时，阅读派生类代码需反复跳转到基类确认是否真在重写；修改基类虚函数签名后，派生类可能静默失效。而有了 override，一眼可知“这是有意重写”，且编译器兜底；有了 final，一眼可知“此处为终点”，避免层层派生失控。
二者配合使用很常见：基类提供虚接口 → 中间类用 override 实现并用 final 封锁 → 派生链在此终止。这种显式契约让协作更可靠，重构更安心。
小提醒：不是所有地方都要加
override 应该加在**所有你本意就是重写虚函数的地方**——漏加可能埋隐患，但加在非虚函数上会编译错误，所以它是安全的“强制自查”。final 则需设计权衡：过早封死可能限制扩展性，应在明确不需要进一步定制时使用。标准库中如 std::string 是 final 类，正是出于稳定性和实现约束的考虑。
