final方法不能被重写但能被继承，因其限制的是“可覆写性”而非“可见性”；子类可调用但不可重定义，编译时报错“Cannot override the final method”，且与private、static机制不同，需依设计意图谨慎使用。
为什么 final 方法不能被重写，但能被继承
因为 final 修饰的是方法的“可覆写性”，不是“可见性”。子类照样能调用父类的 final 方法，只是不能在自己内部用 public void methodName() 去重新定义它。编译器会在子类编译时报错：Cannot override the final method from ParentClass。
常见错误现象：把 final 和 private 混了——private 方法默认不可见、不可继承，而 final 方法是公开可继承、仅禁止重写的。
-
final方法仍遵循访问修饰符规则（比如private final void f()子类既看不到也继承不到） - 接口中不能有
final方法（Java 8+ 接口允许default和static，但不允许final） - 构造方法不能加
final（语法错误，构造方法本就不能被重写）
哪些方法适合加 final：安全、契约、性能敏感场景
加 final 不是为了“锁死代码”，而是明确表达设计意图：这个逻辑不该也不许被改变。
典型使用场景：
立即学习“Java免费学习笔记（深入）”；
- 核心算法入口，比如加密工具类中的
encrypt(String input)，内部调用多个可扩展步骤，但主流程必须一致 - 模板方法模式里已定义好骨架的
execute()，只允许子类重写钩子方法（before()/after()），主干必须final - 返回不可变对象的 getter，如
public final List<string> getNames()</string>（配合返回Collections.unmodifiableList使用更稳妥） - 性能关键路径上的小方法（JVM 可能内联
final实例方法，但别依赖这点做决策）
和 private、static 的区别与误用坑
三者都限制重写，但机制完全不同，混用会出问题。
-
private方法天然不可重写，加final是冗余的（编译通过但无意义） -
static方法属于类，不是实例，所谓“重写”其实是隐藏（hiding），加final能防止子类用同签名static方法去隐藏它 - 如果父类方法是
protected final void init()，子类试图声明public void init()—— 编译直接失败，连访问修饰符都不能改 - 注意：
final对重载（overload）完全没影响，子类仍可定义void init(String s)
IDE 和静态检查容易忽略的细节
很多团队靠 IDE 提示或 SonarQube 检查来发现“该加 final 却没加”的情况，但实际有几个边界点常被跳过：
- 抽象类里的非抽象方法，如果设计上不希望被重写，必须显式加
final；否则子类可以自由覆盖 - Lombok 的
@Getter/@Setter生成的方法默认非final，若需锁定，得手动写或配合@SneakyThrows等注解控制 - 使用字节码增强框架（如 Byte Buddy、AspectJ）时，
final方法可能被绕过或报错，运行期行为和编译期不一致
真正难的不是加不加 final，而是判断“这个方法的语义是否容许被改变”。一旦加了，后续所有子类都得绕开它重构，改起来比删掉还麻烦。
