用class而非实例是因为它轻量、线程安全、jvm唯一，避免提前初始化、绕过代理、破坏单例；典型用于动态代理与延迟绑定，如@lazyservice(interfaceclass=userservice.class)，仅声明契约，不触发初始化。
在延迟加载（Lazy Loading）场景中，注解的 Class 类型参数常被用作类型占位或运行时反射依据，而非直接实例化。它本身不触发类初始化，但为后续按需加载提供关键元数据支持。
为什么用 Class 而不是实例？
Class 对象轻量、线程安全，且 JVM 保证其唯一性；相比传入具体实例，它避免了提前初始化依赖、绕过代理逻辑、破坏单例语义等问题。尤其在 Spring AOP、MyBatis 插件、自定义注解处理器等场景中，Class 是声明“将来要用哪种类型”的最稳妥方式。
典型应用：动态代理与延迟绑定
例如自定义注解 @LazyService(interfaceClass = UserService.class)，框架在真正调用服务前才通过 Class 加载对应实现类（可能走 SPI、Spring BeanFactory 或字节码生成），并创建代理对象。此时：
-
interfaceClass仅用于确定契约，不触发UserService的静态块或字段初始化 - 实际 bean 创建可延迟到第一次
getBean(UserService.class)或接口方法调用时 - 配合
ObjectProvider或Provider<t></t>可进一步解耦获取时机
注意事项：避免隐式类加载
看似安全的 Class 参数，也可能因误用引发提前加载：
- 不要在注解属性中调用
clazz.getDeclaredMethods()等反射操作——这会触发类的链接与初始化 - 避免将
Class直接传给需要实例的 API（如JsonMapper.readValue(json, clazz)），除非确认该调用确实发生在延迟阶段 - 若需默认值，用
void.class或自定义标记类，而非Object.class等通用类型，便于后续判空与策略分发
结合泛型与注解处理器增强类型安全
在编译期，可通过 @SupportedSourceVersion(SourceVersion.RELEASE_17) 配合 RoundEnvironment 获取注解中的 Class 值，并校验其是否为接口、是否具有无参构造器等。运行时再结合 ParameterizedType 解析泛型信息，使延迟加载目标更精确。例如：
@RepositoryLoader(value = OrderService.class, fallback = DefaultOrderService.class)
public class OrderController { ... }
```
注解处理器可提前检查 OrderService 是否存在、是否符合约定，而运行时才决定是否启用 fallback 实现。
