Java 微服务更新，如何减少公共依赖的重复传输
Java 微服务多站点更新时，可以把变化较少的公共依赖与频繁变化的业务内容分开。但前提是打包和启动方式明确支持外部依赖库，并能校验依赖清单和版本。它不是对任意可执行 JAR 直接“删掉 lib”。
重复传输为什么会出现
一个 Java 发布包中，业务代码可能只占一部分，其余是框架、数据库驱动和其他第三方依赖。当每次只修改少量业务内容，却向多个站点反复传输整个包时，稳定依赖也会被一起重传。
如果站点数量、微服务数量或更新频率增加，这一重复传输会更明显。但是否值得分层，仍应根据真实包大小、网络和发布频率判断，不应只为了“瘦身”而增加复杂度。
不能从任意 JAR 中直接删除依赖
可执行 JAR 的结构、类加载方式和启动器可能不同。如果构建结果预期依赖位于包内，直接删除后应用可能无法启动，也可能在运行到特定功能时才暴露缺失。
因此，依赖复用必须先成为明确的构建和运行契约：外部依赖目录在哪里，启动 classpath 如何组成，依赖版本如何锁定，业务包如何与依赖库对应。
用四份内容固定发布契约
- 完整包：用于首次安装、依赖变更或需要回到完整状态时发布。
- 依赖清单：记录依赖名称、版本和完整性校验，并与应用版本关联。
- 轻量业务包：只包含当前启动契约允许独立更新的业务类、资源或模块。
- 启动定义：明确业务包与外部依赖库如何组合，并定义启动后的健康验证。
发布前，先检查站点依赖清单是否与本次业务包匹配。不匹配时停止轻量发布，改用完整包，不在现场临时补单个 JAR。
依赖变了，就回到完整发布
新增、删除或升级依赖，JDK 或启动方式变化，以及无法确认站点依赖库状态时，都应回到完整发布。依赖复用的价值来自稳定、可验证的分层，不是为了少传文件而牺牲一致性。
一个已脱敏的多站点 Java 生产案例中，首次发布建立依赖库，后续更新可发布移除公共依赖的轻量文件，减少重复传输。实际节省量取决于依赖占比、站点数量和网络条件，本文不承诺固定比例。
相关阅读：JAR/WAR 多服务器发布流程 · Spring Boot 多服务器环境差异
如果你已有明确的外部依赖打包契约，可以下载发布助手体验版，用一个非生产站点验证完整包与轻量包两条路径。