避免静态重构失效的关键是让重构不依赖编译期已擦除的注解信息，而应基于AST、字节码属性或编译期固化元数据等不可擦除结构进行判断与执行。

避免静态重构失效，关键不是“绕过”注解擦除，而是让重构行为不依赖编译期已丢失的注解信息。Java 的内置注解（如 @Override、@Deprecated、@FunctionalInterface）默认保留策略为 RetentionPolicy.CLASS 或 RetentionPolicy.SOURCE，意味着它们在类加载后就不可见——IDE 或字节码分析工具若误以为这些注解能在运行时被反射读取、或在重构中被动态识别，就会导致逻辑断连、替换遗漏或条件跳过。

确认注解的保留策略再设计重构逻辑

不是所有注解都“能被看到”。重构脚本、代码生成器或 LSP 插件若基于反射扫描 @Override 来定位可重写方法，注定失败——它只存在于编译期，class 文件里没有对应 RuntimeVisibleAnnotations 属性。务必查清目标注解的 @Retention 值：

• @Override、@SuppressWarnings：@Retention(SOURCE) → 仅编译器可见，javac 后即消失
• @Test（JUnit 4）、@RequestMapping（旧 Spring）：@Retention(RUNTIME) → 可通过反射获取
• @Generated（JSR 269）、@SafeVarargs：@Retention(CLASS) → 存于 class 文件，但不加载进 JVM 运行时

用编译期可观测结构替代注解驱动判断

重构不应靠“运行时有没有这个注解”做分支，而应锚定稳定、不可擦除的语法结构：

• 把 @Override 的语义转化为“方法签名与父类/接口完全一致 + 非静态 + 非私有”，用 AST（如 Eclipse JDT 或 Spoon）直接比对 MethodDeclaration 的名称、参数类型、返回类型和异常声明
• 将 @Deprecated 的调用拦截，改为扫描方法符号引用是否带有 Deprecated attribute（位于 class 文件的 Attributes 区），而非依赖 Method.isAnnotationPresent(Deprecated.class)
• 对 Lombok 注解（如 @Data）这类影响字节码生成的，应在 javac 插件阶段（JSR 269）介入，而不是等 class 文件生成后再用 ASM 分析——因为 Lombok 生成的 getter/setter 本身不带原始注解

区分“重构动作”和“重构依据”，隔离擦除风险

很多重构工具把“依据”（如某个注解存在）和“动作”（如重命名方法）耦合在一起，一旦依据消失，动作就静默跳过。正确做法是分两步：

• 第一步：在编译前期（如 annotation processor 或 Gradle/ Maven 编译任务中）提取并固化元数据。例如，遇到 @ApiStatus.Internal，立即生成一个 internal-methods.txt 列表，存入构建产物
• 第二步：后续的重构任务（如批量改名、权限校验插入）只读这个文本清单，与注解生命周期彻底解耦
• 这样即使注解被擦除、甚至被移除，只要构建流程未变，重构仍按原计划执行

对 IDE 和构建插件做保留策略兼容性验证

不同工具对注解可见性的假设不同。例如：

• IntelliJ 在 “Find Usages” 中能识别 @Override 是因为它解析的是源码 AST，而非运行时反射
• 而某些自研的字节码增强插件若直接调用 method.getAnnotations() 查 @Transactional，却没确认其 @Retention 是 RUNTIME，就会漏掉 Spring AOP 的代理逻辑定位
• 建议在 CI 中加入检查：用 javap -v 查看目标 class 是否含预期的 RuntimeVisibleAnnotations 属性；若无，说明该注解无法支撑运行时重构逻辑