Gradle内部jar打包原理及同项目跨机器构建结果不一致原因咨询

一、构建环境配置差异 #

• JDK版本/发行版不一致：不同版本JDK内置的jar打包工具对ZIP64的默认支持策略不同，低于JDK 1.5的版本默认不支持ZIP64，部分定制发行版也会修改默认参数，当jar条目超过65535时未开启ZIP64就会触发报错。
• Gradle版本不一致：不同版本的Gradle Jar插件默认行为存在差异，比如Gradle 7.0之后调整了ZIP64的触发规则，若两台机器没有统一用Gradle Wrapper、或者全局Gradle配置覆盖了Wrapper版本，就会出现行为差异。
• 文件系统规则差异：Linux默认文件名大小写敏感，Windows、macOS默认大小写不敏感，若项目中存在同名不同大小写的文件，不同系统下生成的文件数量会有差异；同时不同系统对软链接、文件权限的处理逻辑不同，也会导致最终打入jar的条目数不一致。
• 全局环境变量差异：系统级配置的Gradle参数、JDK路径等环境变量会覆盖项目默认配置，导致两台机器实际执行构建的底层工具链不一致。

二、依赖与构建产物差异 #

• 依赖拉取结果不一致：若两台机器配置的Maven、NPM源不同，或依赖声明用了SNAPSHOT、latest这类动态版本，不同时间拉取的依赖内容、数量会存在差异，本地缓存的旧依赖也会导致和最新拉取的依赖不一致。
• 资源构建步骤差异：前端构建类步骤（比如npm install、npm run build）是差异高发区，不同Node版本、包管理器版本（npm 6和npm 7+的依赖结构差异极大）、是否开启production模式，都会导致生成的前端产物文件数量有几倍的差距，如果这类产物会被打入jar包，很容易触发条目数上限。

• Gradle的jar插件是否存在依赖操作系统的实现？
  Gradle官方Jar插件的核心逻辑是JVM实现，本身无操作系统依赖，但其运行行为会受底层JDK版本、操作系统文件系统规则的影响，间接表现出跨系统的差异。
• Gradle是否会优先调用系统自带的zip工具完成jar包压缩？
  默认不会，Gradle默认使用内置的基于JDK的zip实现完成jar打包，只有手动配置调用系统原生工具的情况下才会依赖系统的zip/jar命令。
• 是否是我使用的特定机器本身存在相关硬性限制？
  常规操作系统不存在对jar包条目数的硬性限制，你遇到的报错本质是打包工具未开启ZIP64支持导致的，和系统本身限制无关；仅当机器磁盘不足、文件系统有单文件大小限制时，才会间接影响构建结果。
• 是否是构建过程中的其他步骤在部分机器上会生成更多文件？例如npm install （请谅解，该项目不是我搭建的，我只是参与开发）？
  这是非常高发的诱因，npm install的执行结果受包管理器版本、Node版本、npm配置的影响极大，devDependencies是否被安装、依赖提升规则的不同都会导致node_modules或者构建产物的文件数量出现巨大差异，若这部分内容会被打入jar包，很容易导致条目数超过65535的限制。

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