BeanDefinitionRegistryPostProcessor 是动态注册 Bean 的首选接口，它在 BeanDefinition 注册阶段触发，支持安全新增或修改定义，需设置 class 和 beanName，可控制顺序，且比 ImportBeanDefinitionRegistrar 更适合运行时条件注册。
BeanDefinitionRegistryPostProcessor 是动态注册 Bean 的首选接口
想在 Spring 启动时、Bean 实例化前把自定义 BeanDefinition 注入容器，直接用 BeanDefinitionRegistryPostProcessor。它比 BeanFactoryPostProcessor 更精准——因为它的 postProcessBeanDefinitionRegistry 方法在 BeanDefinition 注册阶段就触发，此时容器里只有原始定义，还没开始实例化，修改或新增都最安全。
常见错误是误用 BeanFactoryPostProcessor 去调 registerBeanDefinition：虽然能编译通过，但若你强制把 ConfigurableListableBeanFactory 转成 DefaultListableBeanFactory 再注册，容易因执行顺序错乱导致 Bean 覆盖失败或重复注册异常。
-
BeanDefinitionRegistryPostProcessor必须被 Spring 扫描到（如加@Component）或显式注册（如通过@Import） - 它的
postProcessBeanDefinitionRegistry方法接收的是BeanDefinitionRegistry接口，原生支持registerBeanDefinition，无需强转 - 若需控制执行顺序，实现
Ordered或PriorityOrdered接口，避免被其他后置处理器覆盖你的注册逻辑
注册 BeanDefinition 时必须设置 class 和 beanName，否则启动失败
手动构造 GenericBeanDefinition 后，至少要调用 setBeanClass 指定真实类型，并用 registerBeanDefinition 显式传入唯一 beanName。漏掉任一环节，Spring 在后续刷新流程中会抛出 BeanDefinitionStoreException 或 NoUniqueBeanDefinitionException。
示例中常犯的错：只 new 出 GenericBeanDefinition，没设 class；或用随机字符串当 beanName，结果和已有 Bean 冲突；又或者把 beanName 写成全限定类名，但 Spring 默认不接受带点号的名字（除非显式开启宽松模式）。
-
beanName必须符合 Java 标识符规范（字母/下划线/美元符开头，不能含点号、斜杠等） -
setBeanClass传入的 Class 必须可被类加载器访问，不能是匿名类或本地类 - 若需注入属性值，用
getPropertyValues().add("propertyName", value)，不是直接 setField
BeanDefinitionRegistryPostProcessor 和 ImportBeanDefinitionRegistrar 的关键区别
两者都能动态注册 Bean，但触发时机和使用场景不同：ImportBeanDefinitionRegistrar 绑定在 @Configuration 类上，由 @Import 驱动，适合基于注解元数据（如 @EnableXxx）做条件注册；而 BeanDefinitionRegistryPostProcessor 是独立 Bean，靠 Spring 自动发现，更适合运行时环境判断（如根据 profile、系统属性、外部配置中心返回值）来决定是否注册。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
一个典型坑是：把 ImportBeanDefinitionRegistrar 当成通用注册入口，在其 registerBeanDefinitions 方法里读取 Environment 或调用远程服务——这会导致 Spring 启动卡在配置类解析阶段，且无法参与 BeanFactoryPostProcessor 链路（比如你无法在它里面修改其他已注册的 BeanDefinition）。
-
ImportBeanDefinitionRegistrar的执行早于所有@Configuration类中@Bean方法，但晚于BeanDefinitionRegistryPostProcessor -
BeanDefinitionRegistryPostProcessor可以拿到完整的BeanDefinitionRegistry和Environment，适合做兜底注册或覆盖逻辑 - 若注册逻辑依赖其他 Bean（如
PropertySource），只能用BeanDefinitionRegistryPostProcessor，因为ImportBeanDefinitionRegistrar此时尚未进入 IoC 容器生命周期
动态注册后，Bean 的作用域、依赖和 AOP 是否自动生效？
是的，只要注册进 BeanDefinitionRegistry，后续所有标准流程都会走通：作用域（singleton/prototype）按 BeanDefinition 设置生效；依赖注入（@Autowired、@Value）照常解析；AOP 代理也正常织入——前提是你的 Bean 类本身满足 AOP 条件（如被 @Service 标记，或匹配了切点表达式）。
但要注意两个隐性限制：一是动态注册的 Bean 不会触发 @PostConstruct 回调（除非你手动设置 setInitMethodName）；二是如果该 Bean 依赖了尚未注册的其他 Bean，Spring 会在实例化时报 UnsatisfiedDependencyException，而不是在注册阶段报错。
- 若需初始化回调，调用
beanDefinition.setInitMethodName("init")，并确保目标方法存在且无参 - 若 Bean 有循环依赖风险，避免在
postProcessBeanDefinitionRegistry中立即调用beanFactory.getBean()获取实例 - 动态注册的 Bean 默认是
singleton，如需prototype，必须显式调用beanDefinition.setScope(BeanDefinition.SCOPE_PROTOTYPE)
实际写的时候最容易忽略的是：注册时机与 Bean 生命周期阶段的耦合关系。比如在 postProcessBeanDefinitionRegistry 里试图获取某个 @Configuration 类中 @Bean 方法返回的对象，这时它根本还没被解析出来——得等后续的 ConfigurationClassPostProcessor 执行完才行。
