final 方法不能重写，这是 Java 的设计约束而非 bug；它用于保障关键逻辑不被覆盖、支持 JVM 优化并明确行为契约；若需定制行为，应采用模板方法、策略模式或组合等替代方案。

final 方法不能重写，这是 Java 的语法规定，不是 bug，而是设计约束。 如果你尝试在子类中重写（override）一个被 final 修饰的父类方法，编译器会直接报错，例如：

error: method xxx() in class XXX cannot be overridden

这是因为 final 明确告诉编译器：“这个方法的实现是最终的，不允许子类改变行为”。所以“怎么重写”本身是个伪命题——它就是不允许重写的。你需要换思路解决实际问题。

为什么报错？本质是设计意图冲突

Java 中 final 用于方法时，核心目的是：

• 保证关键逻辑不被意外覆盖（比如安全校验、核心算法）
• 支持 JVM 更激进的内联优化（提升性能）
• 明确表达“这个行为必须固定”的契约

如果你发现某个 final 方法需要“变”，通常说明当前继承结构或职责划分有问题，而不是语法错了。

立即学习“Java免费学习笔记（深入）”；

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

替代方案：用组合或模板方法代替重写

不靠重写，也能让子类定制行为。常见且推荐的方式有：

• 把 final 方法拆成可扩展的钩子：将原方法改为调用几个 protected 的非 final 模板方法，子类重写这些钩子即可
• 用策略模式 + 组合：把可变逻辑抽成接口，final 方法内部委托给该接口的实例，子类构造时传入不同实现
• 改用抽象方法 + 模板类：如果整个流程固定但某步多变，把类设为 abstract，把要变的部分声明为 abstract 方法，由子类实现

检查是否真需要改父类方法

先确认你是不是误用了继承：

• 子类和父类是否真满足“is-a”关系？有时用组合（has-a）更自然
• 那个 final 方法是不是本就不该被定制？比如 Object.hashCode() 是 final 的，你不会想重写它，而是重写 equals() 和自己的 hashCode() 实现
• 能不能在调用方做适配？比如包装父类对象，对外提供新接口

不推荐的做法（但要知道后果）

以下方式看似“绕过”，但违背设计原则，慎用：

• 删掉 final 关键字（如果源码可控）→ 破坏原有契约，可能引发其他模块异常
• 用反射强行修改（如 setAccessible(true)）→ 违反封装、不可移植、JDK 版本升级易失效
• 用字节码工具（如 Byte Buddy）动态重写 → 复杂、难维护、调试困难

这些属于 hack，只应在极特殊场景（如测试 mock）下临时使用，生产代码应避免。