分层JAR对齐镜像缓存粒度

把整个 fat-JAR 原样拷进镜像里当一层，代价是哪怕只改了一行自己的业务代码，整个包含了所有第三方依赖的层也要重新构建和重新分发——依赖体积通常远大于业务代码，这笔账很不划算。Spring Boot 的分层 JAR 模式把打包结果拆成变化频率不同的四层：第三方依赖（几乎不变）、Spring Boot 启动器类（很少变）、快照依赖（偶尔变）、应用自身的类和资源（经常变），配合 Docker 多阶段构建把这四层分别拷进镜像的四个独立层。这样一来，日常开发只改业务代码时，只有最上面那层”application”需要重新构建和重新下载，生产环境滚动升级时节省的带宽和时间在应用实例多的情况下非常可观。发散：这本质上是把[[镜像分层按变更频率排序]]这条通用原则，从”Dockerfile 指令怎么排”下沉到了”JAR 包内部结构怎么拆”这一层——同一条原则在不同粒度上反复起作用，说明”按变化频率分层”是横跨多个抽象层级都成立的通用优化思路。