控制类路径深度需系统性压缩拓扑层级与依赖半径，核心是将树状依赖压为扁平引用：禁用optional传递依赖、合并同源模块、裁剪spring.factories、拦截深层加载、构建期收敛类路径，并通过jfr、appcds、bean定义数验证效果。
控制类路径深度不是“删掉几个jar”，而是系统性压缩类加载的拓扑层级和依赖传播半径。真正拖慢冷启动的，是深嵌套的间接依赖引发的链式扫描与重复解析——比如一个启动类只用到A.jar里的ConfigLoader，却因A.jar → B.jar → C.jar → D.jar的传递依赖，被迫加载47个无关类，其中12个含静态初始化块。
精简类路径拓扑结构
核心目标是把“树状依赖”压成“扁平引用”。Spring Boot默认的starter机制天然形成多层嵌套，需主动干预。
- 禁用隐式传递依赖：在
pom.xml中对非直接使用的starter显式声明<optional>true</optional>，例如spring-boot-starter-data-redis若仅用于测试模块，就切断它向主启动模块的透传 - 合并同源依赖：将
common-utils、core-model、exception-handler等内部模块统一发布为单个platform-core:1.8.0，避免6个jar包各自加载org.slf4j的桥接类三次 - 检查
BOOT-INF/lib实际内容：用jar -tvf target/app.jar | grep "\.jar$" | wc -l确认是否超过85个——超此阈值后，ClassPathScanningCandidateComponentProvider扫描耗时呈指数增长
拦截并剪枝深层类加载请求
JVM不会主动“跳过”某层依赖，但你可以让ClassLoader在解析到第3层时就拒绝加载非关键包。
- 自定义
URLClassLoader子类，在findClass()中按包名前缀拦截：对com.yourcompany.internal.*、org.apache.commons.logging.*等非启动必需路径直接抛ClassNotFoundException（注意排除日志框架核心类） - 配合
-XX:+TraceClassLoadingPreorder启动参数，生成类加载顺序快照，定位哪些xxxConfiguration$$EnhancerBySpringCGLIB类在启动3秒后才首次被引用，将其所属配置类标记为@Lazy - 对
META-INF/spring.factories做构建时裁剪：用Gradle插件自动移除未启用的ApplicationContextInitializer实现类，减少SpringFactoriesLoader的反射遍历次数
构建期强制收敛类路径宽度
靠运行时拦截是补救，构建期收敛才是根治。重点控制“每个jar能导出多少包”和“谁有权引入新jar”。
- 启用Maven Enforcer Plugin的
banDuplicateClasses规则，同时开启requireUpperBoundDeps——它会报错提示：当guava:31.1和guava:29.0同时存在时，必须统一升至31.1，避免同名类被不同版本重复加载 - 在
gradle.properties中设置org.gradle.configuration-cache=true，关闭Gradle对buildSrc中动态依赖解析，防止构建脚本意外拉入testcontainers等重依赖 - 对所有内部模块启用
api/implementation严格分离：禁止api依赖包含spring-webmvc，改用compileOnly+runtimeOnly组合，从源头阻断web相关类进入启动类路径
验证类路径深度优化效果
不能只看启动时间数字，要确认“深度压缩”确实生效。
- 用
jdk.jfr录制启动过程，筛选ClassLoad事件，统计depth字段分布：优化前80%类加载深度≥4，优化后应有65%集中在深度1–2 - 执行
java -Xshare:dump -XX:SharedArchiveFile=app.jsa -cp target/app.jar生成AppCDS归档后，对比-XX:+UseAppCDS -XX:SharedArchiveFile=app.jsa启动时Loaded shared classes日志行数——应比未归档时少加载35%以上类 - 在
ApplicationContext刷新完成后，调用((DefaultListableBeanFactory) context.getBeanFactory()).getBeanDefinitionCount()，数值应比优化前下降20%–25%，说明无效Bean定义已被剪除
