企业官网建设流程全解析

1. 为什么框架篇是Java面试的分水岭

做了几年Java开发，也面过不少人，我发现一个很规律的现象：简历上写的技术栈都差不多，但一到框架问题就高下立判。很多人能熟练使用Spring、MyBatis写业务代码，但被问到“Bean的完整生命周期有哪些阶段”“Spring Boot自动配置到底怎么生效的”“MyBatis的Mapper接口为什么没有实现类却能直接注入调用”，一下子就答不上来。

框架篇在Java面试里的地位，恰恰就是用来区分“会用”和“懂原理”的分界线。业务代码写得多，不代表你理解框架的设计思想；能跑通Demo，也不代表你能在团队里解决复杂的框架层面问题。面试官考察框架篇，核心目的不是考背诵，而是看三件事：第一，你有没有主动读过源码和官方文档；第二，遇到问题时能不能从原理层面定位和分析；第三，有没有全局视角，知道框架在整体架构中扮演什么角色。

这篇内容适合准备中级和高级Java岗位面试的同学，也适合那些写了两三年业务代码、想系统补一补框架原理的开发。我会结合自己的面试经历和实际工作里踩过的坑，把Spring、Spring Boot、MyBatis、Spring MVC这几个最常考的框架逐一拆开讲，每个部分都会从“面试官为什么要问”出发，再讲核心原理和常见追问，最后给一些实操层面的准备建议。文章偏长，但都是干货，建议收藏后分段看。

2. Spring框架：面试中的绝对重头戏

2.1 IoC容器和Bean的生命周期，考官真正想听什么

IoC（控制反转）这个概念，几乎每个面试者都能说上两句，但大多数人的回答停在“把对象的创建交给Spring管理”这句话上。说实话，这句话放十年前还算新鲜，放在现在只是基本功。面试官追问的深度往往远超这个层面。

我遇到过很多次这样的对话：我先说IoC把对象的创建和依赖关系交给容器管理，面试官点点头，然后紧接着问：“那容器什么时候创建对象？Bean的完整生命周期从哪一步开始？”如果你平时只用过注解，没读过AbstractApplicationContext的refresh方法，这里很容易卡壳。

Bean生命周期其实可以拆成几个关键阶段：实例化前、实例化、属性填充、初始化前、初始化、初始化后、使用、销毁。Spring在实例化Bean之前，会先通过BeanDefinition读取配置，包括XML里的bean标签、注解配置的扫描结果，然后封装成BeanDefinition对象。之后经过合并处理、类加载、实例化策略等步骤，才真正new出对象。实例化完成后，Spring会做属性填充，也就是我们常说的依赖注入环节。接着是Aware接口回调，比如BeanNameAware、BeanFactoryAware，再往后是BeanPostProcessor的before方法、InitializingBean或init-method、BeanPostProcessor的after方法，这时Bean才算准备完毕，可以被业务代码使用了。

这里有个很多人忽略的细节：AOP代理对象的生成，通常发生在BeanPostProcessor的after阶段。所以你在应用里拿到的Bean，很可能不是原始对象，而是一个代理对象。面试中如果能主动提到“Spring通过AbstractAutoProxyCreator在Bean初始化后阶段完成AOP代理的创建”，会明显拉开和普通候选人的差距。

还有一个高频考点是Bean的作用域。singleton和prototype的区别大多数人都知道，但问到“singleton Bean里注入prototype Bean会有什么问题”“怎么解决”，就暴露水平了。默认情况下singleton Bean只创建一次，如果直接注入一个prototype Bean，那这个prototype Bean实际上只有一个实例，每次调用都是同一个对象，失去了prototype的意义。解决办法通常是使用ObjectProvider、Lookup方法注入，或者通过ApplicationContext手动获取。

注意：BeanFactory和FactoryBean是两个完全不同的概念，很多面试者混为一谈。BeanFactory是IoC容器的顶层接口，而FactoryBean是一个特殊的Bean，它本身是个工厂，通过getObject方法产出另一个对象。比如MyBatis的MapperFactoryBean，就是通过FactoryBean机制把Mapper接口变成可注入的Bean。这个区别，至少遇到三次面试官特意追问过。

2.2 Spring AOP的工作原理与切面失效场景

AOP这块，面试官最喜欢从“动态代理的两种方式区别”问起。JDK动态代理基于接口，使用Proxy类在运行时生成代理对象；CGLIB基于继承，通过生成子类来代理目标类。Spring默认策略是：目标类实现了接口就用JDK动态代理，没有实现接口就用CGLIB。Spring Boot 2.x之后默认开启了proxyTargetClass=true，所以即使有接口，默认也用CGLIB。

有个细节值得留意：CGLIB不能代理final类和非public方法。如果你写了一个final的Service类，或者某个方法被final修饰，切面是织入不进去的，因为CGLIB无法继承和覆写。这个点可以作为面试中的加分项提出来，说明你确实踩过类似的坑。

很多人在业务代码里用@Transactional，事务失效了不知道怎么排查。其实事务失效常见原因就那么几类：方法不是public的、异常被catch住没有抛出、自调用导致代理失效、数据库表不支持事务、传播行为配置错误。自调用这个问题最常见，比如同一个类里一个方法调用另一个被@Transactional标注的方法，由于调用发生在对象内部，没有经过代理对象，事务注解就完全失效了。解决办法可以是拆分到不同Bean中，或者使用AopContext.currentProxy()获取当前代理对象。

还有一个切入点：Spring AOP是运行时增强，通过代理实现；AspectJ是编译期增强或类加载期增强，通过字节码操作实现。交易系统或高性能场景中，如果需要更细粒度的切面控制，AspectJ可能更适合。但普通业务项目里Spring AOP已经足够。

2.3 Spring事务：传播行为、隔离级别与失效场景

事务传播行为有七种，面试中至少要被追问三种以上。REQUIRED、REQUIRES_NEW、NESTED这三个是重点。REQUIRED是默认传播行为，如果当前存在事务就加入，不存在就新建；REQUIRES_NEW会挂起当前事务，新建一个独立事务；NESTED是嵌套事务，依赖于JDBC的savepoint机制，回滚时可以只回滚到savepoint位置，而不影响外层事务。

实际开发里我用REQUIRES_NEW处理过一个场景：某个任务执行过程中要写操作日志，日志写入失败不能影响主流程事务回滚，所以日志方法用了REQUIRES_NEW。但后续遇到性能问题，每次主流程提交前都会额外产生一次数据库连接，连接池压力明显变大。后来改成异步写日志，把事务问题也规避掉了。这个例子说明，事务设计不能只盯着正确性，还要考虑连接占用和吞吐量。

隔离级别方面，MySQL默认是REPEATABLE_READ，面试里通常考READ_COMMITTED和REPEATABLE_READ的区别，以及幻读问题。InnoDB引擎通过MVCC解决快照读下的幻读问题，但当前读（带锁的select，如select...for update）还是可能产生幻读。面试时能把“快照读和当前读”分开讲，就比只说“MySQL默认隔离级别”高明得多。

2.4 循环依赖：三级缓存机制，最容易被问到源码细节的问题

循环依赖是Spring的经典考点，也是最能看出候选人源码阅读深度的问题。场景很简单：A依赖B，B也依赖A，两者同时作为singleton Bean被创建时，就会形成循环依赖。

Spring解决循环依赖依赖三个缓存容器，常被称为三级缓存。一级缓存存放已经完成初始化的成品Bean；二级缓存存放早期暴露的原始Bean引用，此时Bean还没完成属性填充和初始化；三级缓存存放的是ObjectFactory，也就是一个回调工厂，用来在需要时生成早期引用，并且可以返回代理对象。

创建A时，A实例化后放入三级缓存，接着填充属性B，发现B还没有创建，就去创建B。B实例化后放入三级缓存，填充属性A时，从三级缓存里拿到A的ObjectFactory并调用getObject，此时A被提升到二级缓存，B拿到A的早期引用，完成属性填充，然后B完成后续初始化并放入一级缓存。A再继续执行属性填充，从一级缓存拿到B，完成后续初始化，也放入一级缓存。

注意一个关键限制：三级缓存解决的是singleton Bean的循环依赖，而且必须是setter注入或字段注入。构造器注入无法解决循环依赖，因为Bean在new的时候就必须传入完整依赖，此时Bean还没实例化完，无法提前暴露。Spring Boot 2.6之后默认禁止了循环依赖，如果你在项目中遇到循环依赖报错，说明代码设计本身有问题，优先考虑重构，而不是把允许循环依赖开关打开。

提示：面试时能把三级缓存的演进原因讲清楚的人很少。一级缓存为了拿成品，二级缓存为了提前暴露早期引用，那三级缓存又解决了什么？答案是解决了代理对象的生成时机问题——AOP代理必须在Bean初始化后阶段才能生成，但循环依赖中的早期引用在生命周期更早的时候就被拿走了。如果不加三级缓存，直接用二级缓存暴露原始对象，那AOP的代理就错过了织入时机。三级缓存通过延迟生成代理的方式，让需要提前暴露时也能返回正确的代理对象。这个理解讲出来，面试官基本会认为你真正读懂了Spring。

3. Spring Boot框架：自动配置与启动原理

3.1 自动配置到底自动了什么

Spring Boot最核心的能力是自动配置，它让开发者不用再写大量XML配置，也不用自己拼装各种Bean。但很多人用了一年Spring Boot，也没完全搞懂为什么引入一个starter依赖，相关的Bean就自动注册到了容器里。

自动配置的核心机制在@SpringBootApplication这个复合注解里，它组合了@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan。其中@EnableAutoConfiguration通过@Import引入AutoConfigurationImportSelector，这个Selector会读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件（Spring Boot 2.7之前的版本读取spring.factories文件），拿到所有自动配置类的类名，然后根据条件注解逐个判断是否需要装配。

条件注解是自动配置的灵魂。@ConditionalOnClass判断classpath下是否存在某个类，@ConditionalOnMissingBean判断容器里是否已经有某个Bean，@ConditionalOnProperty判断配置项是否满足条件。实际工作里最常见的翻车现场就是自己定义了一个Bean，但自动配置也创建了一个，启动时因为类型冲突报错；或者自己定义了一个数据源配置类，结果自动配置的数据源优先级更高，把你覆盖了。理解了条件注解，这类问题就很好定位：先看目标自动配置类上的@ConditionalOnMissingBean条件，再调整自己的配置方式。

3.2 面试必问的启动流程与SpringApplication.run执行过程

面试官问“Spring Boot启动过程做了什么”，其实是想确认你是否看过SpringApplication的源码。直接背步骤没有意义，但你可以用一条主线把过程串起来：先推断应用类型，是Web应用还是非Web应用；然后加载ApplicationContextInitializer和ApplicationListener；接着准备好环境变量和配置；再创建ApplicationContext；最后执行refresh方法加载所有Bean，启动Web容器。

有个细节容易被忽略：Spring Boot默认使用ConfigurableApplicationContext的子类型，Web应用对应ServletWebServerApplicationContext，响应式应用对应ReactiveWebServerApplicationContext。通过WebApplicationType.deduceFromClasspath判断classpath里是否有特定类来决定上下文类型。如果classpath里同时有Spring MVC和WebFlux的类，应用会有一个默认优先级。

3.3 starter机制与自定义starter实战思路

starter的设计逻辑并不复杂：把某个场景需要的依赖和自动配置打包在一起，让使用者通过一条依赖引入整个能力。比如引入spring-boot-starter-web，就能获得内嵌Tomcat、Spring MVC、Jackson等一组依赖。

面试进阶问题通常是“如何自己写一个starter”。这个问题很实操，一般分四步：第一，创建一个自动配置类，用@Configuration和@ConditionalOnClass等注解控制生效条件；第二，在META-INF目录下创建AutoConfiguration.imports文件，写入自动配置类的全类名；第三，定义属性类，用@ConfigurationProperties绑定application.yml里的配置项；第四，需要时提供一个spring.factories里的自动配置排序配置，控制装配顺序。

我做过一个公司内部的短信发送starter，把不同厂商的短信渠道实现封装好，业务方只需要配置channel=smsA或channel=smsB，自动配置类会根据配置创建对应的发送实现Bean。这个方案让三个业务部门接入短信功能时，改动量从几百行配置降到了十几行。自定义starter是体现工程化能力的好素材，面试时如果能讲清楚“为什么用条件注解控制实现选择”以及“如何保证多个starter的配置不冲突”，会很加分。

3.4 Spring Boot配置文件加载顺序与配置覆盖规则

配置文件这块，很多候选人只知道application.yml，不知道profile配置、命令行参数和外部配置文件的优先级。Spring Boot的配置加载优先级从高到低大致是：命令行参数、Java系统属性、操作系统环境变量、application-{profile}.yml、application.yml、classpath内的默认配置。

实际工作中踩过的坑是：本地开发时一切正常，测试环境部署后发现数据库地址不对，排查很久发现是运维在环境变量里配了JDBC_URL，环境变量的优先级高于application.yml，覆盖了配置文件里的值。从此养成了习惯：先打印环境变量里所有的DB相关配置，再怀疑自己代码。面试时提到这个经历不仅能说明你懂配置优先级，还能展示排障思路。

4. 框架面试中的核心疑难与设计思想

4.1 从面试官视角看框架学习：如何展现源码级理解

面试官评估候选人的框架能力，通常不是问你“用过没有”，而是从三个层次递进：使用层、原理层、设计层。使用层是你能说出某个功能怎么配置；原理层是你能解释这个功能底层是怎么工作的；设计层是你能分析框架为什么要这么设计，对比其他方案的优劣。

比如提到MyBatis的一级缓存和二级缓存，使用层回答是“一级缓存是SqlSession级别的，默认开启；二级缓存是Mapper级别的，需要手动开启”。原理层回答是“一级缓存在BaseExecutor中通过PerpetualCache实现，key是CacheKey对象，包含SQL语句、参数、RowBounds等信息；二级缓存通过CachingExecutor装饰器实现，内部有一个装饰器链”。设计层回答则是“一级缓存生命周期太短，只在同一个SqlSession内有效，并发场景下意义有限；二级缓存要解决跨SqlSession共享的问题，但要考虑脏数据问题，因为MyBatis对缓存更新策略是粗粒度的，任何一个更新操作都会清空该Mapper的整个缓存区域”。

能递进到设计层的人很少。这类回答背后的积累不是背题能解决的，而是靠平时深入源码、思考为什么这样实现。建议准备框架面试时，每个核心知识点都用“是什么、为什么、源码怎么实现、有什么局限”四个维度梳理一遍，比刷题效果好得多。

4.2 MyBatis核心原理与高频追问

MyBatis是Java面试中实际出现频率相当高的框架，尤其是业务系统用得多。哪怕你简历里写的是Spring Data JPA，面试官也有可能会问MyBatis，因为它更贴近SQL控制。

MyBatis的启动流程是必问的：SqlSessionFactoryBuilder读取配置文件，通过XMLConfigBuilder解析成Configuration对象，再通过SqlSessionFactoryBuilder.build方法创建DefaultSqlSessionFactory。MapperRegistry负责注册Mapper接口和其对应的MapperProxyFactory。

面试官最常追问的问题是：“Mapper接口没有实现类，为什么可以直接调用方法”。这是典型的动态代理应用场景。MyBatis在解析Mapper时，会为每个Mapper接口创建MapperProxyFactory，这个工厂在获取Mapper时生成MapperProxy对象。MapperProxy是一个InvocationHandler，所有对Mapper接口方法的调用都会走它的invoke方法。invoke方法里会判断调用的是不是Object类的方法，然后通过MapperMethod对象执行SQL。MapperMethod里封装了SqlCommand和MethodSignature，SqlCommand记录SQL语句的类型和ID，MethodSignature解析方法参数和返回类型。执行时通过SqlSession找到对应语句，处理参数后交给Executor执行。

这里有个容易卡壳的追问点：如果Mapper接口里的方法在XML里找不到对应的statement，会报什么错。答案是在MapperMethod初始化时会尝试从Configuration的mappedStatements集合中获取MappedStatement，找不到就抛出IllegalArgumentException，提示Invalid bound statement。如果项目里出现“Invalid bound statement (not found)”报错，基本思路有三个：XML文件的namespace没对应接口全限定名、方法ID没对上、XML文件没有被扫描到。

MyBatis的SQL参数处理机制也值得准备。简单类型参数用#{value}直接取；多个参数时，如果不加@Param注解，MyBatis会把参数包装成param1、param2这样的命名，同时也能用arg0、arg1这种命名。实际开发中强烈建议显式加@Param注解，避免传参逻辑混乱，也让SQL可读性更好。

4.3 Spring MVC请求处理链路与DispatcherServlet

Spring MVC整个请求处理链路是面试中必背的内容，但死记硬背并不可取。用一个请求从进入到离开的过程来叙述，更自然也更完整。

请求到达Servlet容器后，被DispatcherServlet接收。DispatcherServlet的doDispatch方法拿到请求后，先通过HandlerMapping找到对应的HandlerExecutionChain，也就是找到能处理这个请求的Controller方法，以及执行链上挂的拦截器。然后通过HandlerAdapter适配器调用Controller方法。Controller方法返回ModelAndView或者通过@ResponseBody直接返回数据，再经过HandlerMethodReturnValueHandler处理，最后通过MessageConverter将对象序列化成JSON。如果配置了视图解析器，会解析视图名称成真正的View对象并渲染。整个流程中还会执行拦截器的preHandle、postHandle、afterCompletion。

面试官通常会在讲完链路后追问：“拦截器和过滤器有什么区别”。过滤器是Servlet规范里的组件，在DispatcherServlet之前执行，能处理request和response，但不能访问Spring MVC的Handler相关对象。拦截器是Spring MVC提供的，在HandlerMapping找到处理器之后、Controller方法执行之前后执行，可以访问HandlerMethod，适合做登录校验、权限控制、日志记录。

还有个实战细节：一个Controller方法的参数是如何被绑定的。比如前端传了一个JSON对象，后端用一个DTO接收，这个过程涉及HandlerMethodArgumentResolver。其中最关键的是RequestResponseBodyMethodProcessor，它先读取请求体，交给HttpMessageConverter反序列化成Java对象。如果类型转换失败，会抛出HttpMessageNotReadableException，Spring Boot默认把它映射成400错误。理解了这条线，就能很快定位“接口参数解析失败”这类问题。

4.4 微服务与分布式框架面试考点整理

现在很多招聘岗位要求掌握微服务相关框架，这部分在框架篇里比重越来越大。常见考点包括服务注册发现、服务调用、负载均衡、配置中心、服务熔断与降级、分布式事务、分布式链路追踪等，以及网关相关的内容。

针对微服务框架，面试官最爱问的问题大致可以分成两类。一类是概念类：比如“服务熔断和服务降级的区别是什么”，标准回答是熔断是provider端出现故障时的自我保护机制，降级是consumer端在provider不可用时主动提供降级方案，两者有交集但视角不同。另一类是实践类：“你在项目中是怎么做服务划分的”“订单服务和库存服务之间调用失败怎么处理”。

准备这部分时，最好结合自己项目的真实场景来梳理，单纯背概念没有意义。比如我曾经负责过一个支付相关的系统，调用下游回调接口超时时，参考了常见的熔断降级方案，把回调处理设计成重试加补偿的模式，结合消息队列削峰填谷，而不是同步等待超时。这种基于真实场景的经验，比任何概念背诵都更能打动面试官。

JVM调优、线上问题排查、分布式事务方案选择这类问题经常和框架题交叉出现，建议一并准备。比如面试官问“你们系统怎么做分布式事务的”，很多人直接说用了Seata，但要能解释清楚AT模式、TCC模式、Saga模式的区别，以及为什么你的项目选AT模式而不是TCC模式，才更有说服力。

5. 面试中的表达技巧与避坑建议

5.1 如何用“先说结论，再讲原理”的方式回答框架题

框架题容易长篇大论，很多候选人一上来就从底层原理开始讲，讲了五分钟还没说到面试官想问的重点，结果被打断。比较稳妥的回答方式是“结论先行，再展开原理，最后给一个实际例子”。

比如被问到“Spring Boot自动配置原理”，先一句话给结论：“自动配置通过@EnableAutoConfiguration导入AutoConfigurationImportSelector，读取自动配置文件中的配置类类名，再通过条件注解按需装配。”然后展开讲具体流程，提到读取什么文件、关键条件注解有哪些、常见Bean覆盖冲突怎么解决。最后抛一个自己项目里自定义starter的例子。这样的回答结构，面试官可以快速判断你懂不懂，也能顺着你的节奏深挖细节。

另一个技巧是主动暴露“知识边界”。如果某个问题你只知道大概，不知道细节，不要硬编。面试官追问两轮就会被识破，比直接说“这块我没有深入看过”要糟糕得多。诚实地说“这里我了解原理，但没有实际在项目里应用过，我讲讲我的理解，可能没有实战那么深”，反而更能获得认可。

5.2 候选人在框架篇中常见的概念混淆点

见过不少候选人在几个概念上翻车，这里集中整理一下。

第一个是@Component、@Service、@Repository、@Controller之间的区别。从IoC角度来说，它们的功能基本一样，都是把类注册为Bean，@Service、@Repository只是在不同分层语义上做区分。但有一些面试官会追问是否有特殊处理，比如@Repository的异常会被转换成DataAccessException，@Controller能和Spring MVC的HandlerMapping配合。所以不要回答“完全一样”，应该说“核心功能相同，但Spring在某些场景下会做额外处理”。

第二个是@Autowired和@Resource的区别。@Autowired是Spring的注解，默认按类型注入，配合@Qualifier可以按名称注入；@Resource是JSR-250规范里的注解，默认按名称注入，找不到再按类型。很多人只答出“一个按类型一个按名称”，其实还要说出最终默认行为、是否支持强制注入、以及构造器注入场景。

第三个是BeanFactory和ApplicationContext的区别。ApplicationContext是BeanFactory的子接口，两者不仅仅是“更强大的BeanFactory”这么简单。ApplicationContext在启动时默认完成所有singleton Bean的实例化，而BeanFactory是在第一次getBean时才实例化。ApplicationContext还提供了事件发布、国际化支持、资源加载等能力。

5.3 框架源码学习的“最小可行路径”

源码学习最怕贪多嚼不烂。我的经验是：不要从头到尾读Spring源码，而是从一条主链路切入。比如读Bean创建流程，就盯着AbstractApplicationContext.refresh方法，顺藤摸瓜进入finishBeanFactoryInitialization、preInstantiateSingletons、AbstractBeanFactory.getBean，一路到AbstractAutowireCapableBeanFactory.createBean。这个过程中不要纠结每个分支，核心主线看完一遍，再回看具体环节。

阅读源码时需要带着问题读。比如看循环依赖三级缓存源码时，可以带着“一级缓存什么时候放成品”这个问题去翻代码，在DefaultSingletonBeanRegistry里找到addSingleton方法，理解它是在最后一步写入，这样就清楚“成品”和“早期引用”的区别了。

对于时间有限的准备者，我的建议是优先保障Spring IoC和Bean生命周期、Spring Boot自动配置、MyBatis动态代理这几块内容，它们性价比最高。AOP原理、Spring事务、Spring MVC请求链路其次。微服务部分根据自己的项目情况取舍，完全没接触过就不要硬答，否则容易露馅。

6. 框架篇高频问题速查与实战经验总结

结合我个人的几次面试经历来看，框架篇的题目有个共同特点：面试官不太关心你用过什么，更关心你遇到问题时的分析路径。有一次面试中我被问到“如果一个接口偶尔超时，但改一下数据库索引就好了，这说明什么问题”，看起来很偏，但背后考的其实是数据库性能、SQL执行计划、连接池配置这些综合能力，再结合框架中数据源配置和MyBatis SQL执行的链路，才能给出系统性的分析。

准备框架篇面试，与其刷一百道题，不如把核心框架的源码主链路认真过一遍，同时把每个知识点连接到自己的项目实践中。面试中真正出彩的回答，往往不是单纯背诵，而是能讲出“我在某个项目里遇到了这个报错，我是如何根据原理一步步排查出来的”这样的具体故事。这才是框架篇考察的终极目标：通过你对框架的理解，判断你在真实工作中解决问题能力的高低。

最后再分享一个实用的准备方法：找一张白纸，试着不参考任何资料，画一遍Spring请求从启动到处理完成的全流程，以及一个Bean从注册到销毁的完整生命周期。如果能顺畅画出来并解释每个环节的类名和触发条件，说明框架底子已经过关了。画不出来的部分，就是你接下来要重点补的短板。每次面试前用这个方法自查一遍，比临时翻书管用得多。