为什么Spring的Qualifier注解不具备属性解析能力？

这不是Spring的设计缺陷，是@Value和@Qualifier两个注解的设计定位、解析生命周期完全不同导致的预期差。

• 解析阶段完全不同
  @Value的解析逻辑执行于bean的依赖注入阶段，此时Spring容器的环境、属性源、占位符解析器、类型转换器都已经初始化完成，解析${}配置占位符、SpEL表达式本来就是@Value的核心能力，所以可以直接从properties文件取值注入。
  而@Qualifier的作用是在同类型多个bean中筛选可注入的候选对象，它的解析时机早得多——在容器扫描bean定义、匹配注入候选的阶段就会执行。默认的QualifierAnnotationAutowireCandidateResolver不会对注解上的value做占位符解析，只会拿字面字符串和bean的qualifier标识做精确匹配，直接写${xxx}当然无法匹配到目标bean。

• 设计定位不同
  @Qualifier从设计之初就是为了做静态确定性匹配：它的value预期是硬编码的bean名称或者自定义限定符值，目的是在开发阶段就明确同类型多bean场景下的注入绑定关系，避免注入歧义。如果默认支持从配置文件动态读取Qualifier值，就意味着改一行配置就能完全改变依赖绑定关系，很容易出现隐蔽的配置错误，大幅提升问题排查成本。Spring默认不支持这个特性，是明确的设计取舍，而非功能bug。

你贴的自定义QualifierAnnotationAutowireCandidateResolver扩展，是实现动态Qualifier的通用方案，但生产环境使用需要注意两个风险：

1. 该实现在候选bean筛选阶段就会解析占位符，如果占位符对应的配置项是在BeanFactoryPostProcessor执行完成后才加载（比如部分配置中心的延迟加载配置、运行时动态配置），会出现占位符解析失败、注入找不到bean的问题。
2. 动态Qualifier会让依赖绑定关系变成配置驱动的隐式逻辑，排查注入问题时需要同时核对代码和配置，会提升后续的维护成本。如果不是多环境动态切换、多实例动态路由这类强需求，更推荐用@Profile、@Conditional系列注解或者直接明确bean命名的方式实现同类型bean的选择。

内容的提问来源于stack exchange，提问作者Nuan Grobbelaar