核心问题是扫描范围过大与解析深度冗余；应限定路径如acceptPaths("com.example.service")、仅启用enableAnnotationInfo()、确保注解为RUNTIME保留策略，并复用ScanResult避免重复初始化。
大型项目中注解扫描慢，核心问题不在注解本身，而在于“谁在扫”“扫什么”“怎么扫”。Java 注解只是元数据，真正耗时的是反射遍历类、读取字节码、解析 class 文件的过程。优化关键不是减少注解数量，而是精准控制扫描范围与深度。
限定扫描路径，避免全类路径遍历
默认情况下，像 Spring 的 @ComponentScan 或 ClassGraph 的无参 scan() 会扫描整个 classpath，包括 javax.*、org.slf4j、com.fasterxml.jackson 等上百个第三方 jar——这些和你的业务注解完全无关，却占了 80% 以上的扫描时间。
- Spring Boot 中显式指定 basePackages：
@ComponentScan(basePackages = "com.example.app")，禁用默认的包扫描推导 - ClassGraph 使用
acceptPaths("com.example.service", "com.example.controller")，只加载目标路径下的类 - 移除
@SpringBootApplication的自动推导，改用独立组合：@Configuration @EnableAutoConfiguration @ComponentScan(basePackages = "...")
按需启用注解解析能力
很多工具（如 ClassGraph、ASM）默认开启字段、方法、参数等完整字节码解析，但如果你只关心类/方法上有没有 @Transactional 或 @Scheduled，根本不需要读取方法体或字段签名。
- ClassGraph 中只调用
enableAnnotationInfo()，禁用enableMethodInfo()、enableFieldInfo() - 禁用嵌套 jar 扫描：
disableNestedJarScanning()（Spring Boot fat jar 除外） - 跳过运行时 jar 动态扫描：
disableRuntimeJarScanning()，除非你真要处理java.lang.instrument场景
确保注解保留策略匹配使用阶段
注解扫不到，90% 是因为 @Retention 策略不匹配。比如用 RetentionPolicy.CLASS 定义权限注解，却想在运行时用反射拦截——JVM 根本不会把注解加载进内存。
立即学习“Java免费学习笔记（深入）”；
- 所有需运行时反射读取的注解，必须声明为
@Retention(RetentionPolicy.RUNTIME) - 确认注解类本身也在扫描路径内：如果
@MyPermission定义在common-annotation.jar，而该 jar 没被acceptPaths()或@ComponentScan覆盖，注解元信息就无法解析 - 避免误用
RetentionPolicy.SOURCE（如 Lombok 注解），这类注解编译后即消失，任何运行时扫描都无效
复用扫描结果，避免重复初始化
每次 HTTP 请求或定时任务都新建 ClassGraph 实例并调用 scan()，等于反复解压、遍历、解析全部 jar——这是典型的性能反模式。
- 将
ScanResult构建为单例或静态缓存，启动时扫描一次，后续直接查表 - Spring 中可结合
ApplicationContextInitializer或@PostConstruct在容器刷新前完成预扫描 - 对高频访问的注解（如控制器映射），构建内存索引：
Map<string list>></string>，避免每次反射遍历
