BeanFactoryPostProcessor vs BeanPostProcessor: How Spring Hooks Into Its Own Build Process

Spring's IoC container builds beans in two distinct passes: first collecting metadata blueprints from configuration sources, then instantiating live objects from those blueprints. BeanFactoryPostProcessor runs between these two passes, allowing developers to modify bean definitions before any object is created. A common real-world example is PropertySourcesPlaceholderConfigurer, which Spring auto-registers to resolve ${...} placeholders in configuration before beans are instantiated. BeanPostProcessor, by contrast, hooks into the second pass and operates on already-created bean instances rather than their definitions. Understanding this timing distinction — blueprints versus built objects — resolves the widespread confusion between the two similarly named Spring extension points.