接口不能直接作为自定义注解的属性类型——java规范禁止，因注解属性要求编译期可常量化的具体类型，而接口是抽象契约，无法实例化或字面量表示；合法方式是用class
接口不能直接作为自定义注解的属性类型——这是 Java 语言规范明确禁止的。编译时会报错 Invalid type，无论该接口是否被实现、是否为空，都不合法。
为什么接口不能直接用作注解属性
Java 注解属性只允许编译期已知、可常量化（constant）的类型。接口是抽象契约，不具备具体实例或字面量表达形式，无法在编译时确定值，因此不满足注解约束。
- 哪怕写成
MyService service()或Runnable task()，都会触发编译失败 -
Class extends MyInterface>是合法的，但MyInterface本身不是 - 注解中能出现的是“类的类型描述”，不是“接口的运行时引用”
用 Class extends T> 作为接口的合法桥梁
真正可行的方式，是把接口作为泛型上限，用 Class extends YourInterface> 声明属性——它表示“某个实现了该接口的具体类的 Class 对象”，既保留策略意图，又符合语法要求。
- 定义接口：
public interface DataHandler { void handle(String data); } - 注解中声明：
Class extends DataHandler> handler() default DefaultHandler.class; - 使用时传入具体实现类：
@Process(handler = JsonHandler.class) - 运行时通过反射获取并实例化：
clazz.getDeclaredConstructor().newInstance()（需无参构造）
结合 Spring 实现真正的“动态选择”
仅靠注解属性还不够；要让 Class extends X> 活起来，需在运行时结合 Spring 容器做自动装配或策略分发：
- 提前将所有
DataHandler实现注册为 Bean（如加@Component） - 在 AOP 或拦截器中读取注解的
handler()值，再从 Spring 上下文按类型查找对应 Bean：context.getBean(annotation.handler()) - 若需多实现支持，可用
Class extends DataHandler>[] handlers()，配合循环注入或条件匹配
替代思路：用枚举 + 策略映射规避 Class 反射
如果不想处理反射或构造异常，更稳健的做法是：
- 定义枚举列举所有支持的策略：
enum HandlerType { JSON, XML, CSV } - 注解属性用
HandlerType type() default HandlerType.JSON; - 在服务层维护一个
Map<handlertype datahandler></handlertype>，启动时注入各实现 - 运行时查表获取对应实例，完全绕过反射和 classloader 风险
