Java如何实现jar包方法覆盖

Java 类路径覆盖：解决引用 Jar 包无法修改的实战方案

问题

在日常开发中，我们经常会引用第三方 Jar 包或公司内部封装的模块。但偶尔会遇到这样的场景：Jar 包中的某个 Java 类逻辑不符合业务需求，却又无法直接修改 Jar 包源码（比如 Jar 包由其他团队维护、已发布到中央仓库等）。这时候，很多开发者会想到 “路径覆盖”—— 在自己的项目中创建相同包路径和类名的 Java 类，试图覆盖 Jar 包中的类。

方法

在开发模块中建和Jar包中需要修改的类完全一样的路径，在该Package下新建一个同名称的类名，然后复制 jar 包中类的全部方法到新建的类中，在根据实际业务逻辑去调整相对应的方法即可。因为Jar包外代码的优先级高于maven依赖Jar包的优先级，这个时候重写的这个类就会生效了。

注意事项

上面方法可以解决一部分的问题，然而实际操作中，有部分人会遇到 “覆盖不生效” 的问题：项目依然加载 Jar 包中的旧类，自己写的新类完全没起作用。下面在分享一下一些具体解决方案。

一、先搞懂：为什么直接路径覆盖 Java 类会失效？

在开始解决方案之前，我们必须先明白一个核心原理：Java 类加载器的 “双亲委派模型”，这是导致直接覆盖失效的根本原因。
当 Spring Boot 项目启动时，类加载器（默认是ApplicationClassLoader）加载类的流程是这样的：

1. 先委托父类加载器（ExtensionClassLoader）加载；
2. 父类加载器再委托顶层的BootstrapClassLoader；
3. 如果顶层加载不到，再逐层向下尝试加载；
4. 最终，Jar 包中的类会被优先加载（因为 Jar 包通常作为 “依赖资源”，比项目自身的类更早进入类加载路径）。

简单来说：你在项目中创建的 “相同路径 + 相同类名” 的 Java 类，会因为类加载顺序的问题，被 Jar 包中的同名类 “抢占” 加载权。这就是为什么直接路径覆盖会失效 —— 不是路径没配对，而是类加载机制不允许。
另外，即使侥幸绕过类加载顺序，直接覆盖还会导致类冲突：JVM 会认为 “同一个类被加载了两次”，抛出ClassCastException或NoClassDefFoundError，反而导致项目崩溃。

二、2 种可靠方案：替代 “直接路径覆盖” 的实战方法

既然直接覆盖走不通，我们该如何优雅地修改 Jar 包中 Java 类的逻辑？以下 3 种方案，分别适用于不同场景，从简单到复杂逐步递进。

方案 1：用 @Primary 注解优先注入自定义实现（推荐用于 Spring Bean）

如果 Jar 包中的类是 Spring Bean（比如标注了@Component、@Service、@Repository的类），这是最简洁的解决方案。核心思路是：不覆盖原类，而是创建新的实现类，让 Spring 优先加载我们的实现。
实战步骤：
分析原类结构：假设 Jar 包中有一个UserService类，路径是

// Jar包中的原类
package com.example.ca.service;import com.example.ca.service.UserService;
import org.springframework.stereotype.Service;@Service
public class CustomUserService extends UserService