相同项目源码通过Gradle构建生成的Jar包存在差异的原因排查

核心诱因分类 #

1. Gradle版本差异 #

• Gradle跨大版本（如6.x和7.x/8.x）对Java编译参数、依赖解析规则的实现差异极大，部分内置API的默认开启/关闭状态不同，会直接导致生成的字节码结构存在区别
• 若项目未配置gradle wrapper统一构建版本，本地各自安装的Gradle版本不同几乎一定会触发该问题

2. 依赖缓存与解析规则问题 #

• 项目未声明完全固定的依赖版本（如使用+通配符、SNAPSHOT版本依赖），不同时间拉取依赖时会获取到不同的子版本，依赖差异会直接体现在编译后的class文件中
• 本地Gradle缓存中存在损坏的依赖包，或存在同模块不同版本的缓存残留，编译时会优先拉取本地缓存内容，和其他人拉取的全新依赖内容不一致
• 双方依赖仓库配置有差异，如本地配置的私库镜像同步节奏不同，拉取到的依赖版本存在区别

3. 本地环境与编译参数差异 #

• 本地安装的JDK大版本、小版本号不一致，比如同是JDK8，u202和u351的编译器实现存在差异，生成的字节码会有细微区别，部分版本编译的内容会出现跨环境兼容报错
• IntelliJ项目编译配置和Gradle全局配置不统一，比如有人开启了--enable-preview预览特性，有人未开启，最终字节码版本、语法实现完全不同
• 本地配置了自定义的gradle.properties、Gradle环境变量，覆盖了项目默认编译参数，比如编码配置不一致会导致常量池中的字符串内容存在乱码差异

4. 本地变更与文件系统差异 #

• 虽然拉取了相同分支，但本地存在未提交的代码变更、不在Git忽略规则内的临时文件，编译时会被打包进Jar
• 操作系统文件系统大小写敏感规则不同，Windows下类名大小写不一致的文件会被覆盖，Mac/Linux下则会共存，导致最终打包的class文件数量、内容都存在差异

排查验证步骤 #

• 首先执行./gradlew -v（Windows系统执行gradlew.bat -v）核对双方Gradle版本，优先使用项目内置的wrapper进行构建，不要用本地独立安装的Gradle
• 执行./gradlew dependencies导出依赖树，核对双方依赖版本是否完全一致，优先排查SNAPSHOT、通配符版本的依赖
• 核对本地JDK版本，执行java -version和javac -version确认编译用JDK的大版本、小版本完全匹配
• 清理缓存后重新构建：执行./gradlew clean build --refresh-dependencies强制刷新依赖、清理旧构建产物后重新打包，再对比Jar内容

内容的提问来源于stack exchange，提问作者hawarden_