final class 是防止继承篡改的最可靠手段，编译期切断继承路径，JVM 通过 ACC_FINAL 强制拒绝子类加载；安全敏感类、不可变值对象、纯工具类必须加 final；正确写法为 public final class，不可与 abstract 共用，构造器不应为 protected；文档和 private 构造器无法替代 final 的防护力，反射也无法绕过；需注意 Mockito 和 Spring AOP 的兼容性限制。
直接用 final class 修饰类，是防止核心逻辑被恶意继承或篡改的最硬、最可靠的手段——它在编译期就彻底切断继承路径，JVM 字节码层面通过 ACC_FINAL 标志强制拒绝任何子类加载，不存在绕过可能。
哪些类必须加 final 才算真正锁死逻辑
不是所有类都需要 final，但以下三类一旦开放继承，极易引发安全或语义风险，应优先加 final：
-
安全敏感类：如
TokenValidator、SignatureVerifier。若不加 final，攻击者可写class EvilValidator extends TokenValidator，重写verify()方法跳过校验。 -
不可变值对象：如
Money、UserId、OrderId。子类可能通过继承 + 重写equals()或toString()破坏一致性，破坏领域语义。 -
纯工具类：如
JsonUtils、CryptoHelper。只含静态方法，但若未声明 final，他人仍可extends JsonUtils并添加实例方法，污染命名空间、误导调用者。
final 类的写法与常见误区
语法简单，但细节决定是否真正生效：
- 正确写法：
public final class PaymentService { ... }（final 必须放在 class 前） - 错误做法：给 final 类里的方法再加
final（如public final void process() {...}），编译报错——因为类已 final，方法天然不可重写，显式加 final 无意义且非法。 - 别和
abstract共用：语法虽允许，但语义矛盾；抽象类本为被继承而生，final 类禁止继承，二者不可并存。 - 构造器不能是
protected：final 类不允许子类调用super()，所以构造器应设为private或包私有，避免误用。
为什么不能靠文档或 private 构造器代替
它们都不是真正的防护：
- 注释写“禁止继承”没用：IDE 不标红、编译器不拦、子类照写不误，运行时才可能暴露问题。
- private 构造器是副作用：它本意是阻止实例化（如工具类），而非阻止继承；若类提供了 package-private 或 protected 构造器，继承依然成立。
-
反射也绕不过 final：连
Unsafe.defineAnonymousClass或 ASM 动态生成子类都会失败——JVM 规范明确禁止对 ACC_FINAL 类做任何形式的继承。
final 类与测试、框架的兼容提醒
加 final 是设计决策，但需提前评估生态影响：
-
Mockito 3.x 默认无法 mock final 类：会报
Cannot mock class because it is final。如需测试，得升级到 Mockito 4+ 并启用mockito-inline（有性能开销）。 - Spring AOP 无法代理 final 方法：CGLIB 代理会跳过 final 方法，JDK 动态代理则根本无法代理 final 类。若该类需事务、日志等切面，要重新设计代理边界。
- final 不等于性能开关：虽然 JVM 可能对 final 类方法做内联优化，但这只是副产品；核心价值是表达“此处契约绝对稳定”的设计意图。
