必须物理隔离不兼容版本，通过新建shaded-guava26模块并用maven-shade-plugin重命名com.google.common为com.yourcompany.shaded.guava26.common，再安装到本地仓库供主模块引用，实现双版本共存。
当项目中多个模块分别依赖同一库的不同不兼容版本，比如 module-a 用 guava 19.0、module-b 用 guava 26.0，而主模块同时引入二者时出现 NoSuchMethodError，必须让两个版本在运行时不抢同一个类加载路径。
确认冲突根源并拆分隔离模块
先执行 mvn dependency:tree -Dverbose | grep -A 3 -B 3 "guava\|bcprov\|fastjson"，定位哪个模块拉入了哪个版本的冲突 jar；若堆栈报错指向 com.google.common.base.Strings.lenientFormat，说明是高版本方法被低版本类覆盖——此时不能简单 exclude，必须物理隔离。
新建一个空 Maven 模块（如 shaded-guava26），只在它的 pom.xml 中声明 com.google.guava:guava:26.0-jre 依赖，不写任何 Java 代码；【该模块必须独立于主业务模块，否则重命名逻辑会被污染】。
在隔离模块中配置 maven-shade-plugin 的 relocation 规则
方法一：精准包路径重命名
在 shaded-guava26 模块的 pom.xml 的 <build><plugins></plugins></build> 中添加插件配置，关键不是打包成可执行 jar，而是重命名：<relocations></relocations> 节点内指定 <relocation><pattern>com.google.common</pattern><shadedpattern>com.yourcompany.shaded.guava26.common</shadedpattern></relocation>；【必须加
方法二：跳过无关资源处理
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
删掉所有 <transformer></transformer> 配置项——本场景不需要合并 services、不需要设置 Main-Class、也不需要处理 spring.handlers；保留默认行为即可，避免 transformer 干预 relocation 流程。
构建并验证重命名效果
第一步：进入 shaded-guava26 目录，执行 mvn clean package。
第二步：检查生成的 target/shaded-guava26-1.0.0.jar 是否生效：运行 jar -tf target/*.jar | grep "shaded.guava26.common"，应看到大量类似 com/yourcompany/shaded/guava26/common/base/Strings.class 的路径；若输出为空，说明 relocation 未触发，需检查 <pattern></pattern> 是否漏写末尾点或大小写错误。
第三步：将新 jar 安装到本地仓库：mvn install:install-file -Dfile=target/shaded-guava26-1.0.0.jar -DgroupId=com.yourcompany -DartifactId=shaded-guava26 -Dversion=1.0.0 -Dpackaging=jar。
第四步：在主模块的 pom.xml 中，移除原 guava:26.0-jre 依赖，改为引用新坐标：<dependency><groupid>com.yourcompany</groupid><artifactid>shaded-guava26</artifactid><version>1.0.0</version></dependency>；保留原有 guava:19.0 不动。
