Spring Boot中显式调用applicationContext/BeanFactory.getBean()的实际场景？

虽然Spring生态推崇**依赖注入（DI）**作为获取Bean的标准方式，但在一些特定场景下，显式调用ApplicationContext.getBean()或BeanFactory.getBean()是合理甚至必要的，常见场景包括：

• 插件化/动态扩展架构：如果系统支持运行时加载外部插件（比如用户上传的功能Jar包），这些插件类在Spring启动阶段未被扫描到，无法通过@Autowired自动注入。这时候就需要通过getBean()动态获取插件实例，实现功能的热扩展。

• 复杂循环依赖或自定义Bean处理：Spring能处理大部分常规循环依赖，但对于构造器注入的循环依赖、或者自定义BeanPostProcessor内部需要依赖其他Bean的场景，手动调用getBean()可以主动触发Bean的初始化流程，绕过自动注入的限制。

• 框架/工具类开发：当开发通用的Spring扩展工具（比如统一配置管理器、动态任务调度器）时，往往需要根据类类型或名称动态获取Bean。比如一个日志路由工具，需要根据业务标识动态获取对应的日志实现Bean，这时候getBean()是最直接的方式。

• 遗留代码兼容：如果项目是从传统Spring项目迁移到Spring Boot，老代码中存在大量手动获取Bean的逻辑，为了避免大规模重构带来的风险，会保留显式调用getBean()的方式，逐步过渡到依赖注入。

• 测试场景快速验证：在单元测试或集成测试中，有时候需要快速获取某个Bean来验证其状态、或者手动触发特定Bean的初始化流程，这时候用getBean()比配置依赖注入更高效，适合快速编写验证用例。

需要注意的是，显式调用getBean()应该是特殊场景下的选择，而非常规开发方式，滥用会导致代码耦合度升高，违背Spring的依赖注入设计理念。

内容的提问来源于stack exchange，提问作者Piotr Niewinski