企业官网建设流程全解析

简介：这是一份架构师面试题系列中的 Spring Boot 专题资料，以 Word 文档形式收录了 33 道高频面试问答，适合准备架构师岗位面试的开发者、需要梳理 Spring Boot 知识体系的初中级工程师，以及作为团队内部培训与技术复盘素材。资源重点覆盖框架基础、核心功能、自动配置原理、常用 Starter、运行方式、DevTools 热重载、Actuator 监控以及项目创建等关键知识点，问题均由浅入深并附有简明答案，便于快速检索和集中记忆。压缩包内为 1 个 docx 文件，整体大小约 25KB，内容轻量、便于在线预览或下载后直接阅读学习。目前已有 318 人学习过该资源。结合预览内容来看，答案不仅列出结论，还解释优缺点与适用场景，例如对比 YAML 与 properties 配置、说明 JavaConfig 的类型安全与重构友好优势，可帮助读者在理解原理的基础上应对面试追问。

1. 这份 33 题的文档，其实是 Spring Boot 的骨架图

Spring Boot 面试题是 Java 岗位面试里绕不开的硬骨头，但真正让我愿意把这份《架构师面试题系列之 Spring Boot 面试专题及答案（33题）》从头到尾拆一遍的原因，是它在混乱中保留了一条完整的技术主线。33 道题看是散装问答，实际把 Spring Boot 的起步加载、自动配置、配置文件优先级、内嵌容器、监控端点、日志适配这几个核心骨架全串起来了。它不是让你背答案的，而是给你一张「从启动到生产可用」的检查清单。适合两类人：第一类是准备架构师或高级工程师面试的从业者，需要把零散经验整理成能讲清原理的体系；第二类是刚学完 Spring Boot 基础、想确认自己有没有漏掉关键节点的开发者。这两种人读它的方式不同，但都能从中找到自己缺的那块拼图。

2. 基础考点：Spring Boot 是什么、解决了什么，别只会背一句话

2.1 从「简化 Spring」到「独立运行」：答题怎么分层

文档第 1 题回答「什么是 Spring Boot」时，核心是四个能力：简化初始搭建、独立运行、内嵌 Tomcat、简化 Maven 配置。这四个点背下来不难，但面试官真正想听的层次是这样的：

• 第一层：相比 Spring 的 XML 配置时代，Spring Boot 用约定大于配置的方式把「搭项目」这件事自动化了。
• 第二层：内嵌容器意味着应用本身就是一个可执行进程，部署模型从「放到 Tomcat 里」变成了「java -jar 直接跑」。
• 第三层：starter 机制把依赖的版本冲突问题收口到框架内部，开发者不需要自己去对齐一堆 jar 版本。

我一般建议答题时按「它干掉的是什么」来组织，而不是按「它提供了什么」。干掉的是 XML 配置、外部容器依赖、版本管理的心智负担。把这三件事说清楚，比把官方定义背得一字不差更有说服力。

文档第 3 题和第 4 题其实是同一个问题的两个角度。优点题可以从开发期和运维期分开答：开发期是快速创建、自动配置、starter 简化依赖；运维期是准生产监控、内嵌容器。核心功能题刚好反过来，问你「具体有什么」，就把独立运行、内嵌 Servlet 容器、Starter 简化 Maven 配置、自动配置 Bean、准生产监控这五条摆出来。

2.2 JavaConfig 的三种优势：面试里怎么拆解

JavaConfig 在文档里出现了两次（第 2 题和第 26 题），可见它在 Spring Boot 体系里的分量。纯 Java 方式配置 IoC 容器，替代 XML，这背后的三个优势要能展开讲：

• 面向对象：配置本质是类，所以配置类可以继承、可以重写 @Bean 方法，配置逻辑可以复用。
• 类型安全和重构友好：bean 按类型而不是按名称检索，Java 5 泛型让容器在编译期就能发现配置错误。
• 减少 XML 与 Java 之间的上下文切换：XML 和 Java 混用的心智负担，比只用 Java 大得多。

我见过不少人在面试时说「JavaConfig 就是替代 XML 的注解配置」，这个说法太笼统。面试官往下追问一句「配置类怎么继承另一个配置类」就卡住了。文档第 2 题里那句「一个配置类可以继承另一个，重写它的 @Bean 方法」就是最实用的答辩素材。

下面这段代码演示了配置类继承的场景，是 JavaConfig 面向对象特性的典型应用：

// 基础配置类，定义一个数据源 Bean @Configuration public class BaseDataSourceConfig { @Bean public DataSource dataSource() { HikariDataSource dataSource = new HikariDataSource(); dataSource.setJdbcUrl("jdbc:mysql://localhost:3306/base"); dataSource.setUsername("root"); dataSource.setPassword("123456"); return dataSource; } } // 子配置类继承父类，重写数据源 Bean 指向测试库 @Configuration public class TestDataSourceConfig extends BaseDataSourceConfig { @Override @Bean public DataSource dataSource() { HikariDataSource dataSource = new HikariDataSource(); dataSource.setJdbcUrl("jdbc:mysql://localhost:3306/test"); dataSource.setUsername("root"); dataSource.setPassword("123456"); return dataSource; } }

这段代码说明一个问题：当你在测试环境想覆盖数据源配置时，不需要改父类代码，通过继承和重写就能完成环境差异化。两个配置类同时存在时，Spring 会按 @Configuration 的解析顺序和 @ConditionalOnMissingBean 这类条件注解来决定哪个生效。这就是文档第 2 题里「面向对象配置」的真正价值——配置逻辑也是可以分层设计的。参数说明：dataSource() 方法名即 Bean 名称，重写后容器中同名 Bean 的归属取决于配置类的加载顺序。

2.3 DevTools 热重启：答案要说全「生产环境会被禁用」

文档第 5 题问的是「如何重新加载更改而无需重启服务器」，标准答案是 DevTools。但完整答案有三层：

• 原理层：DevTools 会监听 classpath 下的文件变化，触发应用重启。它用的是两个类加载器，base classloader 加载依赖，restart classloader 加载项目类，这样重启比冷启动快。
• 使用层：pom 里加依赖，IDE 里改完代码自动触发，也能手动触发。
• 边界层：DevTools 在生产环境会被自动禁用，通过 spring.devtools.restart.enabled 可以显式控制。另外 DevTools 默认会禁用模板引擎缓存，这对本地调试是福利。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <optional>true</optional> </dependency>

optional 标签很关键，它保证 DevTools 不会被传递到依赖了这个项目的其他模块。有人会把 DevTools 不加 optional 直接引入，结果整个公司的项目都被带上热重启逻辑，就是翻车起点。还有一个冷知识：DevTools 重启和 JVM 的 -Xverify 参数有兼容问题，如果本地启动报 verify 错误，在启动参数里去掉 -Xverify:none 就行。文档第 5 题提到 H2 数据库控制台也是 DevTools 附带的调试功能，这条容易被忽略，实际在面试里提一句会显得你确实用过。

3. 运行与配置：三道高频题背后的真实工程逻辑

3.1 三种运行方式，不是平级罗列而是要分场景

文档第 7 题和第 17 题重复问了「运行 Spring Boot 有哪几种方式」，这说明它是高频中的高频。三种方式：Fat Jar 直接 java -jar 运行、IDE 里跑 main 方法、打 War 包丢外部容器。看起来简单，但面试官想听的是边界。

• 生产环境：Fat Jar。因为 Spring Boot 的 Fat Jar 含内嵌 Tomcat 和所有依赖，一条 java -jar 命令就能起一个完整服务，配合 systemd 或容器编排都很方便。
• 开发调试：IDE 里跑 main 方法，支持热部署和断点，DevTools 在这个场景才能真正发挥价值。
• 遗留系统整合：打 War 包丢进外部 Tomcat。这时要改两点，一是打包方式从 jar 改成 war，二是启动类要继承 SpringBootServletInitializer。文档只说「使用外部 Tomcat 或 Jetty 等容器」，但没提这个细节，属于典型的踩坑点。

@SpringBootApplication public class Application extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { return builder.sources(Application.class); } public static void main(String[] args) { SpringApplication.run(Application.class, args); } }

这段代码是 War 包部署的必要改动。configure 方法会被外部容器调用，用来定位 Spring Boot 的主配置类。注意 main 方法此时只是 IDE 本地调试的入口，真正的启动逻辑在外部 Tomcat 的 Servlet 3.0 规范钩子里。

3.2 配置文件加载顺序：优先级记牢这一条链

文档第 28 题给了配置文件的加载顺序，这是整份文档里最有工程价值的一道题。答案核心是「由 jar 包外到 jar 包内」，顺序整理如下：

这条链背熟只是第一步，关键是理解两个设计意图。第一，profile 配置永远优先于无 profile 配置，这保证了环境差异化配置的独立性。第二，jar 包外部优先于内部，这是 Spring Boot 留给运维的「后悔药」入口——生产环境出问题时，不用重新打包，在 jar 旁边放一个配置文件就能覆盖内置配置。

实践中常见的一个误用是：把数据库密码写进 jar 包内的配置文件，然后运维想改只能重新打包。正确做法是启动命令用 --spring.config.location 指向外部配置文件，或者利用上述优先级把敏感配置外置。文档第 18 题提到的 bootstrap 配置文件则属于另一条线，它优先于 application 加载，主要用于 Spring Cloud Config 配置中心、加密解密场景和少量固定属性。这两种配置文件的职责要分清：application 是应用自身的自动化配置，bootstrap 是拉取远程配置和固定加密属性的前置配置。

3.3 YAML 的层次结构：面试官会追问的细节

文档第 11 题问 YAML 是什么，大多数人答「比 properties 更结构化」就结束了。但这道题的加分项在层次表达。

spring: datasource: url: jdbc:mysql://localhost:3306/demo username: root password: 123456 redis: host: 127.0.0.1 port: 6379

对应的 properties 写法是：

spring.datasource.url=jdbc:mysql://localhost:3306/demo spring.datasource.username=root spring.datasource.password=123456 spring.redis.host=127.0.0.1 spring.redis.port=6379

YAML 的缩进本身表达层级关系，复杂配置的结构一目了然，但缩进错了就是玄学现场。properties 用点号分隔扁平键，对 IDE 自动补全更友好。我个人的习惯是：少量配置用 properties，涉及数据源、多 profile、对象列表时切到 YAML。如果你团队的配置在 Git 里频繁冲突，YAML 的层次结构能减少一些冲突概率，但这算不上决定性优势，选型还是看团队习惯。

4. 自动配置原理与核心注解：拆开 Spring Boot 的黑匣子

4.1 从 spring.factories 到条件注解，一条线讲完

自动配置原理是 Spring Boot 面试的分水岭。文档第 14 题、第 29 题都涉及这个主题，第 14 题讲得比较粗糙，第 29 题给出了完整的五步流程。我把它重新梳理为一条可复述的链路：

启动类标注 @SpringBootApplication，其中 @EnableAutoConfiguration 让 Spring Boot 扫描类路径下所有 META-INF/spring.factories 文件；每个 starter 的 jar 包里都带这个文件，里面列出该 starter 需要的自动配置类；Spring Boot 把这些 xxxAutoConfiguration 类全部加载进容器，但每个自动配置类上都有 @ConditionalOnClass、@ConditionalOnMissingBean 之类的条件注解；只有条件满足时，配置类才真正生效，往容器里注册组件；组件的属性值来自对应的 xxxProperties 类，这些类用 @ConfigurationProperties 和配置文件绑定。整条链路说下来，Spring Boot 的「自动」就变成了可推理的规则，不再是黑匣子。

下面用一个简化版的 spring.factories 内容示意它的结构：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.example.autoconfigure.DemoAutoConfiguration,\ com.example.autoconfigure.CacheAutoConfiguration

每个自动配置类内部通常长这样：

@Configuration @ConditionalOnClass(SomeService.class) @ConditionalOnMissingBean(SomeService.class) @EnableConfigurationProperties(SomeProperties.class) public class SomeAutoConfiguration { @Bean public SomeService someService(SomeProperties properties) { return new SomeService(properties.getHost(), properties.getPort()); } }

@ConditionalOnClass 判断类路径上有没有指定类，@ConditionalOnMissingBean 判断容器里有没有同类 Bean。这两个注解是自动配置生效与否的开关。如果你在自己的 starter 里写自动配置，spring.factories 文件路径和格式错了，配置类根本不会被扫描到，这是最常见的初学者翻车点之一。另外注意，新版 Spring Boot（3.x）改用 org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件来声明自动配置类，spring.factories 方式在新版本中已不再支持自动配置类的注册。如果你面试时能把两代机制的区别讲出来，这道题基本就稳了。

4.2 @SpringBootApplication 的三个组成部分

文档第 19 题和第 27 题都在讲核心注解，足见它有多重要。@SpringBootApplication 是组合注解，由三部分组成：

• @SpringBootConfiguration：本质是 @Configuration，标记这是一个配置类。区别只是语义层面，表达这是 Spring Boot 的配置类。
• @EnableAutoConfiguration：自动配置的入口，负责加载 spring.factories 或 AutoConfiguration.imports 里声明的自动配置类。也可以排除掉某些自动配置，比如 @SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})。
• @ComponentScan：组件扫描，扫描启动类所在包及其子包下的 @Component、@Service、@Repository、@Controller 等。

这个组合注解的威力在于位置决定扫描范围。启动类必须放在根包，否则组件扫描只会扫启动类所在包及其子包，其他包下的 Bean 就注册不进去。实际项目里见过有人把启动类放在 com.example.demo 的最外层，业务代码放在 com.example.demo.module，工作得好好的；也有人把启动类随手放进某个子包，结果大量 Controller 报 404，排查半天才发现是扫描范围问题。

自动配置排除的场景同样频繁：比如你引了 spring-boot-starter-data-jpa 但想用 MyBatis，不排除 DataSourceAutoConfiguration 或 HibernateJpaAutoConfiguration，启动时就会报数据源初始化异常。通过 exclude 属性逐项排除虽然直观，但注意它会写在代码里，属于硬编码配置，不如用 application.yml 里的 spring.autoconfigure.exclude 来控制，运维在配置层面就能调整。

4.3 Starter 的工作机制：为什么它能管住依赖版本

文档第 9、10、13 题反复问 Starter 是什么、常用哪些，因为 starter 机制是 Spring Boot 简化 Maven 依赖的核心手段。它的原理不复杂：每个 starter 就是一个 pom 模块，内部聚合了一批功能相关的依赖，包括第三方库、Spring 相关模块和自动配置类，并指定了一组互相兼容的版本。你引入 spring-boot-starter-web，实际是把 Spring MVC、内嵌 Tomcat、Jackson 等 jar 包一次性拉进来，版本由 Spring Boot 的父级 BOM 统一管理，不需要你自己对齐。

常用 starter 的边界要清楚：

• spring-boot-starter-web：Spring MVC + 内嵌 Tomcat + Jackson，Web 项目标配。
• spring-boot-starter-data-jpa：Spring Data JPA + Hibernate，JPA 路线用。
• spring-boot-starter-data-redis：Redis 客户端 + 连接池，缓存场景用。
• mybatis-spring-boot-starter：第三方 MyBatis 集成，国内项目高频使用。

这里有个细节值得展开：starter 版本的维护机制。Spring Boot 的每个版本对应一组依赖版本清单，由 spring-boot-dependencies 这个 BOM 管理。你引入 starter 时如果不带版本号，会继承父 POM 或 BOM 里声明的版本。但如果你自己引入了某个第三方库而不走 starter，版本冲突就重新出现了。这也是为什么面试时讲 starter 的价值时，一定要提到「版本控制」四个字。

5. 扩展考点与避坑排查：监控、日志、批处理等冷门题的应对

5.1 Actuator 端点与微服务监控的面试死角

文档第 8 题和第 33 题都涉及监控，第 8 题说 actuator 暴露 REST 端点，第 33 题说监控单个微服务的压力。这两题连起来看，真正的考点是「你会不会在分布式场景下用 actuator」。

Actuator 是 Spring Boot 提供的一组端点，通过 HTTP 或 JMX 暴露应用的运行状态。常见端点：/actuator/health 检查应用是否存活，/actuator/info 查看应用自定义信息，/actuator/metrics 查询 JVM、内存、HTTP 请求等指标。但生产环境必须注意端点暴露策略，直接把所有端点全都暴露出去，等于把应用内部状态公开给攻击者。常见的做法是只暴露 health 和 info，其他端点按需开放，并且结合认证机制来保护。

management: endpoints: web: exposure: include: health,info,metrics endpoint: health: show-details: always

show-details: always 表示健康检查返回详细状态，包括数据库连接、磁盘空间等组件健康度。但生产环境要谨慎，细节暴露越多风险越大，通常只在内部监控系统访问时开启。文档第 33 题提到的「50 个微服务需要管理员逐个访问执行端点」确实是痛点，现在的解法通常是搭配注册中心和服务监控面板统一收集，actuator 只负责把数据吐出来，聚合展示由监控平台来做。

5.2 日志框架统一：SLF4J + Logback 的替换链路

文档第 31 题讲 springboot 选用 SLF4J 和 Logback，以及如何把系统中其他日志框架统一到 SLF4J。这道题在实践中的分量很重，因为项目一旦引入多个第三方库，日志框架冲突几乎是必然的。

统一的思路分三步。第一步，排除其他日志框架，比如 Spring 框架里自带的 commons-logging；第二步，用中间替换包把其他框架的调用转接到 SLF4J，例如 jcl-over-slf4j 把 commons-logging 的调用桥接到 SLF4J；第三步，确保底层有 SLF4J 的绑定实现，即 Logback。

实际排除依赖的 pom 配置长这样：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-log4j2</artifactId> </dependency>

这段代码表示替换 Spring Boot 默认的 Logback 为 Log4j2。exclusion 把 starter-logging 移除，再引入 starter-log4j2。这里容易踩的坑是：只用 exclusion 不引入新实现，启动时 SLF4J 找不到绑定实现，直接报错。另外，替换后 log4j2 的配置文件不是 logback.xml，而是 log4j2-spring.xml，放在 src/main/resources 下。如果你之前用过 log4j1 的配置，很多标签都得重写，这也是不少团队宁愿留在 Logback 的原因——换日志框架的成本从来不只是依赖替换。

5.3 常见问题与排查：配置失效、组件 404、热重启失灵

下面整理这份文档对应的高频踩坑点，按「现象 → 原因 → 解决」写。

现象 1：配置了 application.yml 里的属性，但 Bean 里取到的还是默认值。 原因：@ConfigurationProperties 类没有被扫描到，或者配置类上缺少 @ConfigurationProperties 并配合 @Component 注册。 解决：给属性类加 @Component 或 @EnableConfigurationProperties 注册，并确认配置键与字段名一一对应。比如 spring.datasource.url 对应字段名为 url，前缀为 spring.datasource。

现象 2：Controller 明明写了 @RestController，访问却 404。 原因：启动类不在根包下，@ComponentScan 没有扫描到 controller 所在包。 解决：启动类移到项目根包，或者在 @SpringBootApplication 里显式指定 scanBasePackages。

现象 3：改了代码但 DevTools 不自动重启。 原因：DevTools 监听 classpath 变化，IDE 里没有触发编译（class 文件没更新），或者 DevTools 被 optional 声明后本地没有生效。 解决：确认 IDEA 中 Build → Build Project 触发了 class 更新；如果用的是 Gradle，确认依赖引入了 devtools；另外 spring.devtools.restart.enabled 默认开启，不要手动关闭。

现象 4：War 包部署到外部 Tomcat 启动报错，找不到主类。 原因：启动类没有继承 SpringBootServletInitializer，或 configure 方法里 sources 指定错误。 解决：参照前面 3.1 节的代码，继承并重写 configure 方法。

现象 5：自动配置不生效，自定义的 AutoConfiguration 类没被加载。 原因：spring.factories 或 AutoConfiguration.imports 路径错误，或条件注解不满足。 解决：检查文件放在 META-INF 下、类名完整、条件注解引用的类存在于类路径。排查时可以用 --debug 启动，日志里会输出自动配置报告，能看到哪些配置类生效、哪些被排除。

现象 6：引入了 spring-boot-starter-data-jpa 但只想用 MyBatis，启动时报 Hibernate 相关错误。 原因：自动配置同时生效，JPA 和 MyBatis 争抢数据源。 解决：排除 DataSourceAutoConfiguration 或 JPA 自动配置，用 @SpringBootApplication(exclude = {HibernateJpaAutoConfiguration.class}) 或在 yml 中配置 spring.autoconfigure.exclude。

现象 7：HTTP 端口无法启动，报 Web server failed to start。 原因：端口被占用，或 yml 里 server.port 配置被外部参数覆盖。 解决：netstat 或 lsof 查看端口占用；确认启动时是否带了 --server.port 参数，外部参数优先级高于配置文件。

5.4 Spring Profiles：按环境加载 Bean 的完整用法

文档第 23 题讲 Profiles 允许按 dev、test、prod 等配置来注册 Bean。核心场景是：Swagger 只在 QA 环境开启，生产环境不暴露 API 文档。这里给出一个可复现的配置方案。

# application.yml 公共部分 spring: profiles: active: dev # application-dev.yml swagger: enabled: true # application-prod.yml swagger: enabled: false

@Configuration @Profile("dev") public class SwaggerConfig { // Swagger 配置类，只在 dev 环境下加载 }

@Profile 注解标注在配置类上，Spring 在启动时根据当前激活的 profile 决定是否注册这个配置类。注意，spring.profiles.active 本身可以被环境变量 SPRING_PROFILES_ACTIVE 覆盖，这在容器部署时很常用。另外 @Profile 也可以标注在单个 @Bean 方法上，粒度更细。三个 profile 文件同时存在时，公共配置放 application.yml，差异配置放各自的 profile 文件，这个结构是团队协作的基础。

5.5 其他冷门考点：分页、FreeMarker、ActiveMQ 与 Batch

文档第 21、22、24、25、12 题覆盖了分页排序、Swagger、Spring Batch、FreeMarker 和 ActiveMQ 集成。这些题看着杂，但背后有一条主线：Spring Boot 生态对集成组件的封装程度。答题逻辑是「组件是什么 + starter 怎么集成 + 典型配置」。分页用 Spring Data JPA 的 Pageable 传递到 Repository 方法即可，排序用 Sort 对象；Swagger 用于可视化 RESTful API，消费者无需猜测调用方式；FreeMarker 是基于 Java 的模板引擎，做到业务层和表现层彻底分离；ActiveMQ 通过 spring-boot-starter-activemq 集成，无需样板代码；Spring Batch 面向大量记录的批处理，具备事务管理、作业重启、跳过和分区优化能力。

这些题的共同点是都可以用「starter + 少量配置 + 约定用法」来回答。面试官考察的不是你会不会用，而是你有没有踩过集成坑。比如 ActiveMQ 的连接池参数、FreeMarker 的模板缓存开关、Spring Batch 的作业重启幂等性，这些才是真正的经验分。

6. 把 33 题变成自己的题库：一份可执行的考前自测方法

文档本身是问答形式，但直接从头背到尾效率很低，因为题目之间有交叉和重复。我的习惯是把 33 题重组成一份自测清单，按体系而不是按题目顺序过一遍，这样既覆盖高频题，也暴露薄弱环节。

先建立一张二维表格，把 33 题映射到自己的能力地图：

自测的方法是：打开 IDE，不参考文档，尝试写一个最小 Spring Boot 工程。从启动类到 application.yml，再到一个带配置属性的 @RestController，最后加上 actuator 依赖并访问 /actuator/health。这一步能一次性验证知识点 1、4、6、7、8、14、19、27、29。跑通了，基础盘就没问题。

第二步是模拟面试追问。找一个同组的人，让对方从文档里抽题，你口述回答。注意口述和默写不一样，你平时背得再熟，嘴上一紧张就会暴露逻辑漏洞。我一般要求自己做到：每道题不打草稿，先讲结论，再展开一到两个细节，最后补一个踩坑经验。比如问「Spring Boot 自动配置原理」，回答顺序是「spring.factories 扫描 → 条件注解判断 → 组件注册 → properties 绑定」，然后补一个「新版用 AutoConfiguration.imports」的版本差异，再补一个「exclude 属性怎么用」的实战点。一套下来，面试官很难再追问出盲区。

第三步是手工改造一个现成项目。随便找一个老 Spring 项目，尝试把它改成 Spring Boot 结构：引入 web starter、加上启动类、把 XML 配置改成 JavaConfig 和注解、加上 actuator、设置 profile。这个过程中你会真实踩到第 4 章的排坑点，比如组件扫描不到、配置不生效、日志冲突。踩过一次的坑，比背十遍答案记得牢。

最后一句经验之谈。我从那以后每次准备技术面试，都强制自己把别人整理的题库改写成这份二维表格，再花一个晚上把表格里的每一项在项目里验证一遍。验证不了的查文档，查完再验证。文档里的 33 题，本质上就是别人帮你踩过的坑，第一步是看懂，第二步是复现，第三步才是变成自己的。希望这份自测方法对你也有用。

本文还有配套的精品资源，点击获取