final是唯一标准且编译器强制检查的手段，用于阻止类被继承或虚函数被重写；类级写在类名后，虚函数级写在声明末尾，仅适用于虚函数，与override可共存。
用 final 关键字阻止类被继承或虚函数被重写
想彻底禁止某个类被继承，或者防止某个虚函数在派生类中被重写，final 是唯一标准、无歧义的手段。它不是注释或约定，而是编译器强制检查的语法标记。
常见错误是试图靠把构造函数设为 private 或加空虚析构来“暗示”不可继承——这既不安全（友元类仍可继承），也不被编译器识别为设计意图；而 final 一旦写上，任何继承或重写尝试都会触发编译错误，比如：error: cannot derive from 'final' base class 或 error: virtual function 'f' cannot be overridden because it is final。
- 类级别
final：写在类名后，如class Widget final { ... }; - 虚函数级别
final：写在函数声明末尾，如virtual void draw() final; -
final只能用于虚函数（含纯虚函数），对非虚函数加final是语法错误 - 一个函数可以同时是
override和final，例如：void f() override final;
override 不是防重写的工具，而是防误写的契约
override 的唯一作用是告诉编译器：“我本意是重写基类的某个虚函数”，如果基类根本没有匹配的虚函数签名，编译器立刻报错。它不阻止重写，反而鼓励正确重写。
典型误用场景：忘记加 override，结果因参数类型微小差异（如 const int* vs int*）或 const 限定符不一致，导致新增了一个重载函数而非重写，运行时调用的仍是基类版本——这种 bug 很难察觉。
立即学习“C++免费学习笔记（深入）”；
- 必须显式写在函数声明末尾，如
void process() override; - 仅适用于成员函数，且该函数必须是虚函数（继承自基类虚函数或自身带
virtual） - 若基类函数是
final，再加override会触发冲突错误，这是好事：说明你试图违反设计约束
不加 final 的类/函数，其实无法真正“防住”继承或重写
C++ 没有运行时封禁机制，所有“防止”都依赖编译期约束。如果你只靠文档说“请勿继承”，或靠私有构造函数+友元绕过访问控制，那只是增加门槛，而非阻止。只要有人愿意写友元、用模板特化、甚至用指针强转，就能绕过这些“软限制”。
真正可靠的防线只有两处：一是类定义时加 final，二是虚函数声明时加 final。其他方式要么无效，要么引入额外复杂度（如 PIMPL + 私有实现类），还可能破坏 ABI 兼容性或影响内联优化。
- 把基类析构函数设为
protected+virtual，只能阻止栈上实例化，不影响堆上继承 - 用
static_assert在模板中检测继承关系？只对模板实例化生效，不覆盖普通继承 -
final是唯一能被所有标准编译器一致支持、零开销、语义清晰的方案
兼容性与实际使用注意点
final 和 override 都是 C++11 引入的关键字，所有现代编译器（GCC 4.7+、Clang 3.0+、MSVC 2015+）均完整支持。但要注意它们不是标识符，不能用作变量名或函数名。
- 旧代码迁移到 C++11 后，建议逐步给明确不希望被重写的虚函数加上
override，能提前暴露大量隐性错误 - 若类设计之初就确定永不扩展，应直接加
final；后期补加需评估已有派生类是否受影响 -
final类中的虚函数自动变为 final，无需重复标注（但显式写上更清晰） - 不要为了“统一风格”在非虚函数后加
override或final——编译器会直接拒绝
真正容易被忽略的是：即使用了 final，也不能替代逻辑上的封装设计。比如一个 final 类内部仍可能暴露过多细节，或虚函数虽不能重写，但可通过组合注入行为。防继承和防重写只是接口控制的第一层，不是万能锁。
