Spring MergedBeanDefinition 如何揭示 Bean 实例化属性覆盖及依赖注入的执行顺序？

本文共计917个文字，预计阅读时间需要4分钟。

MergedBeanDefinition 不是运行时动态生成的活定义，而是在Spring的doCreateBean流程中，调用createBeanInstance之前，完成合并并缓存下来的最终蓝图。它决定了：

关键点在于：它不参与实际对象创建，但直接控制后续所有注入行为。比如你写了一个子 Bean 继承抽象父 Bean，那 getMergedBeanDefinition("userService") 返回的对象里，getPropertyValues() 已经包含 version=1.0.0（继承）和 name=用户服务（覆盖），不会再变。

属性覆盖发生在 MergedBeanDefinition 阶段，不是 populateBean 时才决定

很多人误以为“XML 或 @Bean 中写的 @Value 是在属性注入阶段才解析”，其实不然。属性值的合并与覆盖，早在 AbstractBeanFactory.getMergedBeanDefinition() 调用时就完成了：

• 父 Bean 的 <property name="enabled" value="true"></property> 和子 Bean 的 <property name="enabled" value="false"></property>，在合并时后者直接覆盖前者
• @Value("${app.timeout:3000}") 中的默认值 3000 也在这一阶段解析为字面量，进入 MutablePropertyValues
• 若子 Bean 没有声明某属性（如 version），则保留父定义中的值；一旦声明，无论是否为空字符串，都视为“显式覆盖”

这意味着：你在 postProcessMergedBeanDefinition 回调里拿到的 beanDefinition，其 getPropertyValues().getPropertyValue("xxx") 返回的就是最终将被注入的值，不是原始配置片段。

依赖注入顺序依赖 MergedBeanDefinition 中的元数据，而非代码书写顺序

populateBean 阶段执行字段/方法注入时，并不按 Java 源码里 @Autowired 出现的先后顺序来，而是严格依据 MergedBeanDefinition 中缓存的 InjectionMetadata 列表——这个列表由 AutowiredAnnotationBeanPostProcessor.postProcessMergedBeanDefinition 构建，顺序是：

• 先扫描所有 Field（通过 ReflectionUtils.doWithLocalFields），按反射返回的字段数组顺序排列（JVM 保证类文件中字段顺序）
• 再扫描所有 Method（doWithLocalMethods），同样按字节码顺序
• 构造器注入不走这里，它在 createBeanInstance 阶段就已完成，早于 MergedBeanDefinition 合并

所以如果你发现 @Autowired private A a; 总比 @Autowired private B b; 先注入，不是因为你写了 A 在前，而是因为 JVM 加载 class 时 A 字段排在 B 前面——这个顺序在 MergedBeanDefinition 缓存 InjectionMetadata 时就已经固定了。

容易忽略的坑：MergedBeanDefinition 是只读快照，改了也没用

有人试图在 MergedBeanDefinitionPostProcessor 中调用 beanDefinition.setScope("prototype") 或修改 getPropertyValues()，期望影响后续实例化——这是无效的。因为：

• RootBeanDefinition 在合并后被设为 isFrozen = true，多数 setter 会直接抛 IllegalStateException
• 真正起作用的是 applyMergedBeanDefinitionPostProcessors 方法内部对 injectionMetadataCache 的填充，而不是改定义本身
• 如果你需要动态干预注入逻辑，应该实现 InstantiationAwareBeanPostProcessor 或重写 resolveDependency，而不是动 MergedBeanDefinition

最常踩的坑是：在 postProcessMergedBeanDefinition 里 log 了一堆字段，却没意识到这些字段的注入时机早已由该回调触发的 findAutowiringMetadata 决定了，后续无法靠“改定义”绕过。