为何ListableBeanFactory默认不考虑父上下文？修改默认行为有何风险？

背景说明 #

与BeanFactory接口不同，ListableBeanFactory默认不查询父应用上下文的Bean，官方推荐用BeanFactoryUtils实现跨上下文查询。但这种方式在自定义代码中有效，部分Spring集成场景（比如Spring MVC无法找到父上下文的Rest控制器）却不适用——尽管Spring MVC可通过AbstractDetectingUrlHandlerMapping的setDetectHandlersInAncestorContexts方法开启父上下文扫描，但并非所有功能都有这类配置项。为此，我实现了继承DefaultListableBeanFactory的ParentConsideringBeanFactory，将其设为应用上下文的默认Bean工厂，目前运行正常，但想了解以下问题：

1. Spring 为何让ListableBeanFactory默认不考虑父上下文？ #

核心源于上下文分层隔离的设计初衷，具体原因包括：

• 职责边界清晰：Spring的上下文层级（比如全局父上下文、Web子上下文）是为了实现关注点分离——父上下文承载全局共享资源（如数据源、服务层Bean），子上下文专注特定领域（如MVC控制器、视图解析器）。ListableBeanFactory的定位是查询当前上下文内部的Bean集合，默认不包含父上下文能严格区分不同层级的职责，避免子上下文过度依赖或滥用父上下文的Bean。
• 避免意外冲突：若父、子上下文存在同名Bean，默认查询父上下文会导致子上下文的Bean被“覆盖”，破坏“就近优先”的层级覆盖逻辑。只查当前上下文能确保子上下文的Bean优先级更高，符合开发者对子上下文定制化Bean的预期。
• 性能与明确性：遍历父上下文会增加Bean查询的性能开销，而且显式通过BeanFactoryUtils查询父上下文，能让代码意图更清晰——开发者明确知道自己要跨上下文获取Bean，避免无意识引入父上下文的Bean导致的行为模糊。

2. 使用ParentConsideringBeanFactory修改默认行为可能引发的问题？ #

自定义实现打破了Spring的原有设计约定，可能带来以下隐患：

• 上下文隔离失效：子上下文会获取到父上下文的所有Bean，模糊了层级职责边界。比如子上下文的MVC控制器扫描会包含父上下文的Bean，可能导致重复注册、请求映射冲突等问题。
• 同名Bean冲突：若父、子上下文存在同名Bean，自定义工厂会同时返回两个实例（或优先返回父上下文的实例），导致依赖注入时获取到非预期的Bean，引发业务逻辑错误。
• Spring组件兼容性问题：Spring大量内置组件（如事务管理器、事件监听、MVC的HandlerMapping）都是基于ListableBeanFactory只查当前上下文的逻辑实现的。修改默认行为后，这些组件的扫描范围扩大，可能引发不可预期的行为，比如事务配置被父上下文的Bean覆盖、事件监听器重复触发等。
• 维护与升级风险：后续Spring版本对ListableBeanFactory的逻辑调整（比如查询优化、Bean定义规则修改）可能与你的自定义工厂产生兼容性冲突，增加升级维护的成本。
• 调试难度提升：当出现Bean相关问题时，需要同时排查当前和父上下文的Bean定义，定位问题的复杂度大幅提升。

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