spring boot启动时因引用已删除注解类而解析失败，属系统级构建熔断；需排查properties/yml、xml配置、@import/@componentscan等硬编码引用，并清理ide与maven缓存。
注解类文件被删除后，代码里还留着对它的引用，Spring 启动时解析失败、编译报错甚至整个构建流程中断——这不是“编译不通过”那么简单，而是典型的系统级构建熔断。关键不在删没删干净，而在引用是否被 Spring 容器或构建工具真正“看见”并尝试加载。
检查所有非 Java 源码中的硬编码引用
Java 编译器只管 .java 文件，但 Spring 的启动过程会扫描 XML 配置、properties/yml、@Import、@ComponentScan 路径、甚至第三方框架的元数据（如 MyBatis 的 mapperLocation）。只要这些地方写了已删除类的全限定名，就会在容器刷新阶段触发 ClassNotFoundException 或 BeanDefinitionParsingException。
- 逐个排查 application.properties 或 bootstrap.yml 中是否含 xxx.class=xxx.xxx.DeletedConfig 这类配置项
- 搜索项目中所有 XML 文件（尤其是 spring-context.xml、spring-mvc.xml），确认
已清除 - 检查 @Import({DeletedConfig.class})、@ComponentScan(basePackages = "xxx.xxx.deleted") 等注解值，它们不会被 IDE 重命名自动更新
启用构建阶段的类路径预检机制
Maven 和 Gradle 默认不校验类引用是否存在，直到运行时才暴露问题。可在构建流程中插入静态分析环节，提前发现“悬空类引用”。
- 用 Maven 插件 maven-enforcer-plugin 配合 requirePluginVersions 和 banDuplicateClasses，防止旧版依赖带入已删类
- 集成 javaparser 写轻量脚本，在 compile phase 扫描所有 .java 文件中 import 语句，再比对当前 classpath 是否存在对应类（可跳过 JDK 和第三方 jar，专注本项目包）
- Gradle 用户可在 build.gradle 中添加 doLast 任务，调用 ClassLoader.getResource() 尝试加载疑似类，失败则 failBuild
用反射或 SPI 替代硬编码类名
如果业务逻辑必须动态加载某类（比如策略工厂、插件机制），避免直接写死类名字符串——这类引用 IDE 不识别、编译不报错、运行才崩，最难排查。
- 把类名从字符串挪到配置中心或数据库字段，启动时用 Class.forName() 加载，并包裹 try-catch 记录告警而非抛异常中断
- 改用 Java SPI 机制：定义接口 + META-INF/services/xxx.Interface，让实现类自行注册，Spring Boot 可用 SpringFactoriesLoader 加载
- Spring 原生支持 @ConditionalOnClass，配合 @Configuration，让含已删类的配置块自动跳过，不参与 Bean 构建
清理 IDE 和构建缓存再验证
Eclipse/IntelliJ/VSCode 的索引和 Maven 的 target/classes 可能残留旧字节码或解析缓存，导致“明明删了还报错”。
- IDEA：File → Invalidate Caches and Restart → “Invalidate and Restart”
- Eclipse：Preferences → General → Network Connections → Cache → 清空全部
- Maven：执行 mvn clean compile -U（-U 强制更新快照依赖）
- 检查 target/classes 下是否还有 deleted-package 目录，有则说明资源拷贝未同步清理
