Java注解参数必须编译期确定，但可通过组合注解、自定义处理器、外部配置（如@Value、@ConfigurationProperties）或AOP解析SpEL等方式实现灵活配置，注解仅声明意图，具体值运行时注入。
Java 注解本身不能在运行时“动态传参”，它的参数必须在编译期确定（即写死在代码里），但通过组合注解、自定义处理器、配合外部配置（如 Spring 的 @Value、@ConfigurationProperties）或元注解，可以实现「看起来灵活」甚至「真正灵活」的业务配置能力。
用注解声明配置意图，实际参数由外部注入
这是最常用且推荐的方式。注解只负责标记「哪里需要配置」和「配置类型」，具体值从配置文件、环境变量或数据库加载。
- 定义一个注解，比如
@EnableFeature，带一个value()或name()属性用于标识功能名 - 在配置类中读取
application.yml中对应 key 的值（如feature.order.timeout=3000） - 用
@ConfigurationProperties或@Value("${feature.order.timeout}")把值注入到 Bean 中，再结合注解标记的位置做逻辑分支 - 示例：你写
@EnableFeature("order")，系统自动查feature.order.*下的所有配置项并启用对应策略
用注解 + AOP 实现运行时参数解析
适用于需要根据上下文动态决定行为的场景，比如日志采样率、降级开关、灰度路由等。
- 定义注解如
@RateLimit(key = "#userId", permitsPerSecond = 10)，其中#userId是 SpEL 表达式 - 用
@Aspect拦截被该注解标记的方法，在通知中解析 SpEL（借助StandardEvaluationContext）获取真实参数值 - 把解析出的
userId和预设的permitsPerSecond一起交给限流器（如 Guava RateLimiter 或 Redis 分布式限流） - 这样注解声明的是规则模板，执行时才绑定真实数据，达到“灵活配置”效果
用元注解 + 条件化注解组合控制启用逻辑
当配置影响的是「是否创建某个 Bean」或「是否生效某段逻辑」时，Spring 的条件化注解是更自然的选择。
- 自定义注解
@ConditionalOnFeatureEnabled("payment.alipay")，内部用@Conditional(FeatureCondition.class) -
FeatureCondition实现matches()方法，去查配置中心或本地配置，判断该 feature 是否开启 - 配合
@Import或@Bean方法，实现按需加载组件，避免硬编码 if-else - 好处是配置变更后，只需刷新配置（如 Spring Cloud Config + RefreshScope），无需重启服务
避免直接在注解里塞复杂参数
注解属性只能是常量表达式：基本类型、String、Class、枚举、其他注解、以及它们的一维数组。不能是对象、集合、Lambda 或运行时计算结果。
- ❌ 错误示范：
@MyLog(level = LogLevel.DEBUG, formatter = new JsonFormatter())——new不合法 - ✅ 正确做法：用字符串标识（
formatter = "json"），运行时查表映射到具体实例；或用枚举限定可选值（formatter = Formatter.JSON） - 如果真需要复杂结构，改用配置类（
@ConfigurationProperties）+ 注解标记作用域，分工明确
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
