mergedbeandefinition 是 spring 在 createbeaninstance 前合并完成并冻结的只读蓝图，固化属性注入、构造器、初始化方法等元数据，决定后续所有依赖注入行为。
什么是 MergedBeanDefinition，它在实例化前就定型了
MergedBeanDefinition 不是运行时动态生成的“活”定义，而是 Spring 在 doCreateBean 流程中、调用 createBeanInstance 之前就完成合并并缓存下来的最终蓝图。它决定了：哪些属性要注入、用哪个构造器、初始化方法是谁、是否延迟加载、@Autowired 字段/方法有哪些——这些全部固化在 RootBeanDefinition 实例里。
关键点在于：它不参与实际对象创建，但直接控制后续所有注入行为。比如你写了一个子 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 决定了，后续无法靠“改定义”绕过。
