使用maven-shade-plugin的功能可重命名冲突依赖包路径，如将org.bouncycastle.改为com.yourcompany.shaded.bc.，新建shading模块单独处理、限定子包范围、验证类路径变更后，主项目直接引入shaded包即可隔离类冲突。

直接用 maven-shade-plugin 的 功能，就能在打包时把第三方包的路径整体改掉，让冲突类“各过各的”，不抢同一个类名空间。

先确认到底哪里冲突了

别一上来就配插件。先搞清是哪个包、哪几个类在打架：

• 运行 mvn dependency:tree | grep -A 3 -B 3 "bcprov\|jackson\|kafka"，看哪些依赖拉进了同名 artifact（比如两个不同版本的 bcprov-jdk15on）
• 查报错堆栈，找到具体加载失败的类全名，例如 org.bouncycastle.crypto.params.RSAKeyParameters
• 用 jar -tf 或反编译工具打开两个 jar，确认它们真有相同包+相同类，不是只是名字像

新建一个 shading 模块来单独处理

不要在主项目里直接 shade 全局依赖——容易误伤。推荐另建一个空 Maven 模块（如 shaded-bcprov），只负责重命名那个冲突依赖：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• pom 中只声明要被重命名的那个依赖，比如 bcprov-jdk15on:1.70
• 配置 maven-shade-plugin，重点写 块
• 指定原始包名前缀（org.bouncycastle.）和新前缀（com.yourcompany.shaded.bc.）
• 可加 限定只重命名 crypto.* 或 asn1.* 这些实际用到的子包，避免把测试类或无关工具类也挪走

打包后验证是否生效

执行 mvn clean package 后，检查生成的 jar 是否真的“变脸”成功：

• 用 jar -tf target/shaded-bcprov-1.0.jar | grep "shaded.bc" 确认类路径已更新
• 解压 jar 查看 com/yourcompany/shaded/bc/crypto/params/RSAKeyParameters.class 是否存在
• 如果这个 jar 是给 Hutool 这类库用的，插件会自动把 Hutool 编译后的字节码中对 org.bouncycastle.crypto.* 的引用，全部替换成新路径——不用改一行源码
• 把新 jar 作为普通依赖引入主项目，原冲突依赖（比如低版本 bcprov）仍保留，不再 exclude

主项目里怎么用这个 shaded 包

主项目的 pom 中这样写就行：

• 保留原有冲突依赖（如旧版 bcprov-jdk15on），不 exclude
• 显式添加你刚打好的 shaded 包：com.yourcompanyshaded-bcprov
• 确保 shaded 包的 scope 是 compile（默认），让它参与编译和运行时类加载
• 运行时，JVM 加载 com.yourcompany.shaded.bc.crypto.* 和 org.bouncycastle.crypto.* 是完全独立的两套，互不影响