Spring与SpringMVC父子容器：Bean查找规则、经典踩坑与Boot演进

“Spring和SpringMVC为什么需要父子容器”这个问题，杀伤力在于：背过答案的人都能讲出“父容器放Service，子容器放Controller”，但你再往下问“这个结构是怎么搭起来的”“Bean在父子容器之间怎么查找”“为什么有人在这个结构里把事务配失效了”，很多人就开始含糊了。我面过不少候选人，十个里有九个能说到这个分层，真正能把话聊透的，一只手数得过来。这篇文章就从这个“看着简单”的问题出发，把Servlet时代背景、Bean可见性规则、双容器配置方式、经典踩坑和Spring Boot里的变化一并理清。如果你是刚学Spring，放心往下看，我会从最常见的两个报错场景入手；如果你已经工作几年，建议重点看第5节和第6节，那部分内容普通文档里写不到。

1. 先从两个报错场景说起：Bean找不到和事务不生效不是配置偶然

1.1 Controller注入Service，居然报NoSuchBeanDefinitionException

SSM项目里最经典的一幕：Controller里写了@Autowired注入一个UserService，启动后在Tomcat控制台看到NoSuchBeanDefinitionException: No qualifying bean of type 'com.example.service.UserService'。

新手第一反应是检查Service类上有没有@Service注解，检查<context:component-scan>的base-package是不是漏了。结果发现注解有、包路径也包含service包，还是报错。折腾半天后发现，原来是两个配置文件“各管了一段”——applicationContext.xml扫了service包，spring-mvc.xml只扫了controller包，按理说Controller在子容器，子容器会沿着parent引用去父容器找Service，应该能注入才对。但如果ContextLoaderListener没有配置，或者父容器的扫描路径里根本没包含service包，那么这个Service就真的不存在于容器体系中，Controller再聪明也拿不到。

这个例子看着基础，实际上把父子容器的核心价值问出来了：Spring MVC中Controller之所以能拿到父容器里的Service，靠的就是“子容器向上查找”这个机制。如果没有父子关系，Controller只能在自己所在的ApplicationContext中找Bean，SSM这种分层架构根本没法定下来。

1.2 事务注解在Controller调用链中静默失效

比Bean找不到更隐蔽的，是@Transactional不生效。一个Service方法上标了@Transactional，数据库操作抛了异常，数据居然没回滚，日志里也看不到事务拦截的痕迹。

排查时发现一个典型配置错误：spring-mvc.xml里加了<aop:aspectj-autoproxy/>，applicationContext.xml里没有配置任何事务驱动。Service由父容器创建，切面在子容器里配置。@Transactional靠的是BeanPostProcessor在Bean初始化阶段生成代理，而BeanPostProcessor只对当前容器创建的Bean生效。父容器创建的Service，不会被子容器里配置的AOP逻辑增强，结果就是事务静默失效，异常被吞掉，数据库数据留下脏数据。

这种问题在SSM时代可以说一踩一个准，因为它不报错、不崩溃，只会在用户下单时少扣一次库存。等你在几百个Controller里定位一圈，时间成本早就爆炸了。这个案例说明一个关键点：容器层级不是随便拆着玩的，Bean在哪个容器里注册，就被哪个容器的机制处理。父子容器不是简单的“存放位置不同”，它决定了一个Bean能不能被代理、被谁代理、被哪些切面拦截。

2. 父子容器的诞生逻辑：Servlet容器、Listener与DispatcherServlet的三角关系

2.1 两个“容器”根本不是同一个东西

要弄懂父子容器，先得把两个“容器”的概念分开。

Tomcat是Servlet容器，它管理的是Servlet、Filter、Listener这些Web组件的生命周期；Spring是IoC容器，它管理的是Service、Dao、Controller这些业务对象的生命周期和依赖关系。Spring MVC想要在Tomcat里跑起来，就得在Web应用启动时创建Spring IoC容器，并把DispatcherServlet注册到Tomcat里。

但这里有个问题：Tomcat启动Web应用时，整个应用还处于初始化阶段，Spring容器由谁来创建？创建完以后放在哪里？Filter、Listener这类不经过DispatcherServlet的组件，又怎么访问Spring容器里的Bean？这些问题的答案，就是父子容器结构的骨架。

2.2 ContextLoaderListener为什么天然适合做父容器

在传统web.xml部署方式里，我们会配置一个ContextLoaderListener：

<listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:applicationContext.xml</param-value> </context-param>

ContextLoaderListener实现了ServletContextListener。Web应用启动时，Tomcat会回调它的contextInitialized方法，在这里创建一个根上下文（Root WebApplicationContext），并把配置文件解析、Bean扫描、Bean定义注册、单例Bean创建这些完整流程走完。这个根上下文会被挂到ServletContext的ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE属性上，供整个应用全局访问。

根上下文里放什么？数据源、事务管理器、Service、Dao，也就是所有业务层和持久层的Bean。对任何一个Web应用来说，这些Bean理应是全局共享的。Filter要做权限校验，需要调UserService；@Scheduled定时任务线程，需要调业务方法；甚至其他第三方框架集成，也可能需要拿到Service引用。它们都不经过DispatcherServlet，唯一能访问Spring容器的地方，就是这个根上下文。没有ContextLoaderListener，这些组件就只能手动从Spring容器里拿Bean，或者干脆自己new一个容器，结果就是一堆重复的对象。

2.3 DispatcherServlet为什么还要单独搞一个子容器

再看DispatcherServlet的配置：

<servlet> <servlet-name>dispatcher</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcher</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

DispatcherServlet在init时同样会创建一个WebApplicationContext，专门放HandlerMapping、HandlerAdapter、ViewResolver、Controller这些Web层组件。问题来了：为什么不把Controller直接丢进父容器，所有Bean放一起多省事？

原因有两个。

第一，一个Web应用可以部署多个DispatcherServlet，比如一个管前台页面请求，一个管后台接口请求，它们的URL映射不一样。如果所有Web组件堆在一个容器里，两个Servlet之间的Bean会互相污染，A的Controller可能被B的HandlerMapping处理到。拆成每个DispatcherServlet一个子容器，配置和组件就隔离了，互不干扰。

第二，Servlet规范里，Servlet实例是Tomcat管理的，它只是“在某个时机被回调”。DispatcherServlet需要自己拉起一套Spring MVC环境，这套环境和全局业务容器不该混在一起。父容器提供公共底座，子容器是可以插拔的Web模块，这样的边界更清晰。

2.4 官方其实没有强制要求“必须父子”

回到标题的问题：为什么需要父子容器？往根上说，这不是Spring拍脑袋设计出来的，而是Servlet规范里Web应用启动方式倒逼出来的产物。

Spring本身并不强制容器分父子，ApplicationContext完全可以只有一层。但在传统WAR包部署模式下，ContextLoaderListener在ServletContext阶段启动，DispatcherServlet在Servlet阶段启动，两者的生命周期起点不同，职责也不同。为了让多个Servlet共享同一套Service层配置，同时保留各自独立的Web配置，Spring MVC就采用了“当前上下文向上关联根上下文”的分层结构。

这段历史决定了，父子容器是一个为了适配环境而生的结构，不是绝对的架构设计真理。这也是为什么后来Spring Boot敢把它简化掉——下面第6节会专门展开。

3. Bean查找的可见性规则：子容器能拿父容器的东西，反过来不行

3.1 getBean在父子容器间的委托逻辑

父子容器之间的关系，在Spring里由HierarchicalBeanFactory接口定义。子容器执行getBean("userService")时，不是直接去父容器拿，而是走一套固定顺序：

1. 先在自己的BeanDefinitionMap里查有没有名为“userService”的Bean定义；
2. 有，则从自己的单例池里返回（没有就在自己容器里创建）；
3. 没有，则检查parentBeanFactory是否为null；
4. parent不为null，委托父容器执行同样的getBean流程；
5. 父容器也没有，才抛出NoSuchBeanDefinitionException。

所以你会发现一个有意思的现象：从子容器里getBean("service")拿到的是父容器的那个单例实例，但子容器自己在单例池里不会缓存这个实例。因为Bean不是由子容器创建的，子容器只是“借用”了父容器里的对象。每次从子容器出发向上查找，最终都会落到父容器的单例池里。

这个机制用一个生活化类比就是：孩子找东西先翻自己书包，找不到就问家长，家长给了就用；但这个东西不会因为孩子问了一次就变成孩子书包里的东西。东西最后还是家长的。

3.2 父容器为什么看不到子容器的Bean

容器可见性最核心的规则是：子容器可以看到父容器的Bean，父容器看不到子容器的Bean。

这不是Spring偷懒，而是有意为之。因为委托查找方向是单向的——getBean是从当前容器向上找parent，而不是从parent向下找child。父容器在创建UserService时，如果想注入一个OrderController，它找遍自己所有BeanDefinition都没有，因为OrderController注册在子容器里，父容器根本不知道它的存在。

这条规则在SSM架构里反而成了一个意外的好处：业务层代码天然拿不到Web层组件。Controller可以调用Service完成业务逻辑，Service想反向拿到Controller去操作视图层？不行，容器层级不允许。这相当于从机制层面逼着你分层，而不是靠代码规范、靠人review。

我应该强调的是：对于老项目，这确实是一种解耦约束；但对于Spring Boot单容器项目，这个约束已经不存在了，一旦项目演进到Boot，需要靠架构习惯来继续维持分层意识。

3.3 父子容器里同名Bean的“遮蔽”现象

还有一种隐蔽情况：父容器和子容器都定义了相同名称或相同类型的Bean。比如applicationContext.xml里扫了com.example.service，spring-mvc.xml里也扫了com.example.service，结果UserService被注册了两份，一个在父容器、一个在子容器。

此时从Controller注入UserService，子容器会优先返回自己创建的那个实例，父容器里那个“同款Bean”被彻底遮蔽，永远走不到。但注意，父容器里的实例并不会消失，它依然存在于父容器的单例池中，只是子容器侧不引用它。

这带来的最现实后果是：同一个类，在应用里可能同时存在两个实例。一个用了自己的状态，一个用了另一份状态。如果这两个实例都持有某个缓存集合、某个计数变量，状态就会彼此不同步，而且极难排查。这个问题在第5节还会继续展开，这里先留个印象。

4. 双容器的标准搭法：从web.xml到Java Config

4.1 web.xml是最直观的“双容器说明书”

我建议所有学Spring MVC的人，至少在代码里看一遍传统web.xml的完整配置，因为它把父子容器的形态暴露得最清楚。

前面已经列过ContextLoaderListener和DispatcherServlet两段配置，这里把它们组合到一起看：

<context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <servlet> <servlet-name>dispatcher</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dispatcher</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

注意两个容易被忽略的细节：

• 父容器的配置文件路径通过<context-param>指定，参数名是contextConfigLocation，这是ContextLoaderListener读取的；
• 子容器的配置文件路径通过<init-param>指定，参数名同样叫contextConfigLocation，但作用域是dispatcher这个Servlet自己，由DispatcherServlet读取。

两个参数同名不同命，分别服务两个容器。如果只在<context-param>里配置了配置文件，DispatcherServlet不指定自己的配置文件，它会去默认位置找/WEB-INF/dispatcher-servlet.xml，找不到时子容器里就是空的Web配置。

另外，<load-on-startup>1</load-on-startup>必须配，否则DispatcherServlet会延迟到第一个请求到达时才初始化，子容器也跟着延迟创建，启动期可能不会暴露问题，但第一个请求会非常慢，而且容易在运行期突然发现容器还没初始化完。

4.2 Java Config：AbstractAnnotationConfigDispatcherServletInitializer

到了Servlet 3.0+时代，可以用Java配置替代web.xml。Spring MVC提供AbstractAnnotationConfigDispatcherServletInitializer，子类只需要实现三个方法：

public class MyWebAppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer { @Override protected Class<?>[] getRootConfigClasses() { return new Class<?>[] { RootConfig.class }; } @Override protected Class<?>[] getServletConfigClasses() { return new Class<?>[] { WebConfig.class }; } @Override protected String[] getServletMappings() { return new String[] { "/" }; } }

看名字就能对应上：getRootConfigClasses提供的是根上下文（父容器）的配置类，getServletConfigClasses提供的是DispatcherServlet上下文（子容器）的配置类。这套API本质上仍然是父子容器结构，只是把web.xml的表达方式换成了类型安全的Java类。

在我实际经验里，用Java Config的人还容易犯一个错：RootConfig里的@ComponentScan把Controller的包也扫了，WebConfig里的@ComponentScan又把Controller的包扫了一遍。两个容器各创建一份Controller，只是请求处理时真正用的是子容器里那个。你看着代码没什么问题，但应用启动后内存里多了一堆无用对象，排查内存占用时还挺难发现的。

4.3 两个配置文件的职责划分

配置完以后，一定要在纸上把两个文件的职责画清楚：

记住一个原则：和请求处理链路相关的组件放子容器，和全局业务能力相关的组件放父容器。Controller是请求入口，放子容器；事务是业务能力，放父容器；切面横跨业务能力，也放父容器。

至于@Configuration类本身，如果同一个配置类同时被两个容器的扫描路径命中，它会被两个容器各加载一遍，这不算错，但要注意配置类里定义的Bean如果之间互相依赖，可能会产生意想不到的双实例。所以我自己处理老项目时，会把根配置和Web配置拆成两个独立的配置类，避免同一个类被两个容器同时加载。

5. 双容器最容易踩的坑：重复扫描、代理失效、手动new容器

5.1 扫描范围重叠：同一个Bean被创建两遍

先看一段非常容易出现在SSM项目里的配置：

applicationContext.xml里：

<context:component-scan base-package="com.example" />

spring-mvc.xml里：

<context:component-scan base-package="com.example" />

如果两处都配置了相同的扫描包，结果不是“Spring自动去重”，而是在父容器和子容器中分别扫描、分别注册。com.example包下所有带@Component、@Service、@Repository、@Controller标记的类，会在两个容器里各出现一次。同一个类，被创建了两个独立实例。

为什么不会报错？因为Spring容器的单例作用域只保证“在一个容器内”单例，不跨容器。两个容器各有各的单例池，天然允许相同类型、相同名称的Bean各自存在。

后果我在第3节提过：状态同步问题、内存浪费、AOP代理不统一。更麻烦的是，当你给某个Service加缓存注解，你会看到缓存有时候生效有时候不生效——因为请求链路里Controller注入的是子容器里的Service，而定时任务线程拿到的可能是父容器里的Service，两份对象各用各的缓存，行为自然不一致。

5.2 AOP代理只在创建它的容器里生效

这是我一直想重点强调的坑。Spring的AOP代理是通过BeanPostProcessor在Bean创建过程中织入的，而BeanPostProcessor只作用于它所在容器管理的Bean。

举个例子，如果事务切面和<aop:aspectj-autoproxy/>配置在spring-mvc.xml（子容器），而Service由父容器创建，那么Service在父容器中初始化时，子容器里的AOP处理器根本不在场，Service不会被代理，事务注解也就不会被解析。

反过来也一样，如果你把Controller注册到父容器，把AOP配置放到子容器，Controller同样不会被增强。

这个坑的修复方式很简单：事务、AOP、缓存这些全局能力，必须放在和业务Bean同一个容器里。既然Service在父容器，那@EnableTransactionManagement、<tx:annotation-driven/>就应该在父容器配置。Controller特有的切面（比如日志打印）可以放在子容器，它只针对Controller生效。

如果你不是一眼能看出“切面在哪个容器生效”，有一个调试技巧：在目标方法里打印this.getClass()。被代理的对象类名会包含cglib或jdk.proxy字样，没被代理的类名就是原始类名。这个技巧在排查父子容器导致的AOP失效时非常有效。

5.3 手动new ApplicationContext的连环问题

老项目中还有一种“野路子”写法：由于某些Filter或线程池拿不到Spring容器里的Bean，程序员就直接在代码里写：

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml"); UserService userService = context.getBean(UserService.class);

这段代码跑起来通常不会立刻报错，所以它的隐患特别隐蔽。它会把applicationContext.xml里的所有Bean重新加载一遍，创建一个全新的容器。这个新容器里的单例对象和原有的容器对象完全没有关系，Service被实例化成两套——一套给Spring容器用，一套给这段代码用。两套对象的数据库连接、缓存、线程状态都不一样，运行一段时间后就会出现“接口调用正常，但定时任务操作的数据和接口看到的数据不一致”这种诡异问题。

正确做法是从ServletContext中拿根上下文：

WebApplicationContext context = WebApplicationContextUtils.getRequiredWebApplicationContext(servletContext); UserService userService = context.getBean(UserService.class);

WebApplicationContextUtils会从ServletContext的属性中读取ContextLoaderListener放进去的根上下文，拿到的是同一个容器、同一套单例对象，不会重复创建。

5.4 面对“找不到Bean”，我建议按这个顺序排查

如果你在SSM项目里遇到Bean相关异常，别急着改代码，先按下面顺序走一遍：

1. 查启动日志，确认Root WebApplicationContext initialization completed和Initializing Spring DispatcherServlet两行日志都出现了，且顺序是先根后DispatcherServlet；
2. 确认发生异常的这个Bean应该属于父容器还是子容器，然后检查对应配置文件的扫描路径；
3. 在Controller中注入ApplicationContext，调用context.getParent()，如果不为null，说明这个Controller确实运行在子容器中；若parent就是null，说明你的项目压根没有父子结构；
4. 用context.getBeanDefinitionNames()把当前容器内已有的Bean名打出来，过滤出目标类型，看它到底注册在哪一侧；
5. 最后再检查是否存在两个容器都扫描同一包的情况，如果存在，立即拆分配置。

这套排查路径我用了很多年，基本能覆盖90%以上的父子容器异常场景。比在IDE里盲目打断点快得多。

6. Spring Boot为什么把父子容器收编成单容器

6.1 Spring Boot的默认世界：一个ApplicationContext包含所有Bean

有人统计过，从SSM迁到Spring Boot以后，和父子容器相关的报错几乎绝迹。原因很简单：Spring Boot默认不再使用ContextLoaderListener+DispatcherServlet这种两套上下文装配方式。

在Spring Boot的Web项目中，SpringApplication.run()创建的是一个ServletWebServerApplicationContext。数据源、事务管理器、Service、Dao、Controller、HandlerMapping，全都注册在这一个ApplicationContext里。业务Bean和Web组件不再被拆成两拨，整个应用只有一个根容器。

我之前写Spring Boot时还专门验证过：在@RestController里注入ApplicationContext，调用getParent()返回的是null。这在传统SSM项目的Controller里几乎不可能出现——传统结构下Controller里的ApplicationContext一定有parent。

所以面试时听到“Spring Boot是单容器、没有父子结构”这种说法，在业务主线上是成立的。严格抠源码的话，内嵌Tomcat启动DispatcherServlet时，它仍然可能创建一个极其空壳的子上下文，但这个子上下文里几乎没有用户自己定义的Bean，所有实际Bean都在根容器里。对使用者来说，它已经不具备传统父子容器的特征了。

6.2 什么时候还值得保留父子容器

虽然Spring Boot默认不收这套，但在某些场景下，双容器结构依然有价值：

• 传统WAR包部署的老项目，已经在用web.xml+ContextLoaderListener，没必要强行改成单容器；
• 需要多个DispatcherServlet，每个Servlet想拥有不同的Web层配置，比如一个面向API、一个面向后台管理，且两者需要共享同一套Service；
• 团队希望靠容器机制强制“业务层不反向依赖Web层”，把架构约束内建在容器层级中。

如果你是新建Spring Boot项目，我不建议为了“还原历史”刻意模仿父子容器。Boot的单容器设计已经证明，绝大多数项目根本不需要那个层级，保留反而不利于排查。

6.3 老项目改造时，最值得做的三件事

如果你要从SSM迁到Spring Boot，或者只是维护一个还在用双容器的老项目，我按实际经验给出三个优先级很高的建议：

1. 统一扫描入口。在传统结构中，父容器只扫Service、Dao等业务组件，子容器只扫Controller。在Spring Boot中，这两种Bean统一由主启动类所在包扫描。如果老代码里有多个@ComponentScan，合并时一定要检查有没有重复包路径，避免把Controller和Service扫进同一个BeanDefinition集合导致定义覆盖。
2. 事务配置跟着容器走。确认@EnableTransactionManagement和业务Bean都在同一个容器。
3. 不要在业务代码里手动获取ApplicationContext读取Web层对象。原本靠容器层次提供的隔离，一旦迁到单容器就失效了，跨层依赖一定要靠代码规范补上，比如Service接口里就禁止出现HttpServletRequest、HttpServletResponse这类Web参数类型。

我在实际项目中见过太多人迁Boot之后，把Controller里塞满HttpServletRequest，再传给Service做逻辑处理。这在传统双容器结构下父容器看不见子容器，Service类里的Web依赖不会被正常注入，反倒早期会暴露问题；到了Boot单容器时代，Web类型在任意层都能拿到，隐患反而被“藏”起来了，代码很快腐烂成一层到底的“面条代码”。

所以我的态度一直很明确：容器结构可以简化，但分层意识不能简化。想法上，这是比Spring容器本身更值得维护的工程原则。

最后再分享一个我个人的判断标准：如果你在任何Spring项目里看到WebApplicationContextUtils和getParent这两个API同时出现，基本可以确定这是一个双容器结构的项目。这时候所有排查思路都应该先问一句“这个Bean在哪个容器里”，而不是急着看注解有没有写对。搞懂父子容器，很多时候不是为了理解一个历史遗留设计，而是为了在SSM遗址、老系统改造和面试现场，都能一眼看出问题到底出在哪一层。