“SpringBoot 是什么很多人背了一堆注解却仍然说不清楚它到底做了什么。”这是许多 Java 开发者学习路径上最真实的状态。大家用 RestController 写接口、用 Service 写业务、用 Autowired 注入对象觉得 SpringBoot 就是“Spring 的简化版”可一旦被问到“自动装配原理”“Starter 到底是什么”“为什么启动一个项目不需要配置 Tomcat”就会陷入一种似懂非懂的尴尬。这篇文章想帮大家把这个问题彻底理清楚。我会从 SpringBoot 提出的背景、它在 Spring 生态中的真实定位、它替开发者做的具体事情入手再深入到自动装配原理和后端项目落地。这是系列的第一节内容偏“认知框架”和“快速上手”目标是让你读完不仅知道 SpringBoot 好用还能说清楚它为什么好用、好在哪里、核心机制是怎么设计的。1. SpringBoot 到底是什么不是“又一个新框架”很多初学者容易把 SpringBoot 误认为是一个和 Spring 并列的独立框架这是第一个认知误区。实际上SpringBoot 并不是重写了一套新框架而是构建在 Spring Framework 之上的“开发基础设施”。它做的事情用一句话概括就是让 Spring 应用可以“开箱即用”。你可以把 Spring Framework 理解为发动机。发动机很强大但把它装到车上还需要变速箱、底盘、电气系统、轮子等一系列配套。传统模式下这些配套需要你手工组装而 SpringBoot 直接提供了一辆“能开就走”的整车并且它没有改动发动机本身。具体到技术层面SpringBoot 提供了几个关键能力自动配置根据项目引入的依赖和 classpath 情况自动生成需要的 Bean。Starter 依赖管理把一组功能相关的依赖打包成“套餐”解决版本兼容问题。内嵌 Servlet 容器项目无需外置 Tomcat、Jetty 即可独立运行。生产级运维特性健康检查、指标采集、外部配置等能力内置在框架中。这意味着SpringBoot 不是“替代 Spring”而是“重新组织 Spring 的使用方式”。你写的业务代码仍然是 Spring Bean你用的依赖仍然是 Spring 生态的组件只是装配逻辑从“自己写 XML”变成了“框架自动判断”。这种模式一般被称为“约定优于配置”SpringBoot 把这种思想从口号变成了工程落地。2. 回到“配置地狱”没有 SpringBoot 之前有多痛要理解 SpringBoot 的价值最好是回到它出现之前的时代。当时一个典型的 Java Web 项目也就是我们常说的 SSMSpring Spring MVC MyBatis架构从创建到启动需要手工完成大量重复配置。在 web.xml 里配置 Spring 的 ContextLoaderListener 和 DispatcherServlet在 spring-mvc.xml 里开启注解驱动、配置视图解析器、静态资源映射在 applicationContext.xml 里配置数据源、事务管理器、MyBatis 的 SqlSessionFactory 和 Mapper 扫描。这还只是基础配置。如果项目要集成 Redis、消息队列、定时任务对应的配置会继续膨胀。我举一个很小的例子光是 Spring MVC 的基础配置片段就足够劝退新手!-- web.xml 中的核心配置片段 -- servlet servlet-namedispatcher/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class init-param param-namecontextConfigLocation/param-name param-valueclasspath:spring-mvc.xml/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namedispatcher/servlet-name url-pattern//url-pattern /servlet-mapping这还只是 web.xml 的冰山一角。除了配置本身还有两个更折磨人的问题第一依赖版本需要手工维护。SSM 项目要引入 Spring、Spring MVC、MyBatis、MyBatis-Spring 等依赖每一个组件的版本都要自己确认兼容性。遇到版本冲突时排查两个 jar 之间的依赖关系会消耗大量时间而 Maven 的依赖树却只是冷冰冰的列表。第二部署链路很长。开发完代码后需要打成 war 包再把 war 包放到本地安装的 Tomcat 的 webapps 目录下启动 Tomcat才能看到效果。这个过程虽然只多了 3 到 5 步但每台开发机的环境不同经常出现“在同事电脑上能跑在我电脑上报错”的问题。把这两件事叠加起来一个普通的新项目从创建到能够在浏览器里看到第一个页面很多时候需要大半天。而 SpringBoot 出现后新项目从创建到启动只要几分钟。这不是操作熟练度的问题而是整个使用范式被重写了。3. SpringBoot 的四大动作它替开发者做了哪些事SpringBoot 实现“开箱即用”靠的是四个核心动作。把它们拆开看清楚你对 SpringBoot 的理解就会从“知道”变成“掌握”。3.1 Starter 起步依赖依赖管理从“点菜”变成“套餐”过去引入依赖是“点菜”逻辑我先决定要 Spring MVC再去决定要不要 Jackson还要考虑 JSON 序列化用哪个库比较合适。每个决定都代表一次潜在的错误判断。SpringBoot 换成了“套餐”逻辑。你只需要引入一个 starter例如 spring-boot-starter-web这个套餐里就自动包含了 Spring MVC、内嵌 Tomcat、Jackson、Spring Boot 自动配置模块等一组与 Web 开发相关的最佳实践依赖。你不用关心具体版本SpringBoot 的依赖管理机制已经把这些组件的兼容版本通过 spring-boot-dependencies 统一锁定。这种设计最直接的收益是你只需要关心“我要做什么功能”而不是“我要引哪些 jar”。3.2 自动配置基于条件的智能默认值自动配置是 SpringBoot 看起来“魔法”的部分。它的核心思路是框架根据你引入的依赖和当前环境自动创建你“大概率需要”的 Bean。举例来说当你引入了 spring-boot-starter-web 并且 classpath 中包含 Spring MVC 相关类时SpringBoot 会悄悄帮你创建 DispatcherServlet、内嵌 Tomcat、HandlerMapping、异常处理器等一系列 Web 开发必需的组件。你可能一个 Bean 都没写过但项目启动后 Web 能力就已经完整可用了。这个机制的关键在于“有条件”。自动配置并不是无条件地把所有 Bean 都注册进去而是通过条件注解逐个检查只有满足条件才装配。这就保证了引入的功能越多项目越复杂SpringBoot 的自动装配也能保持足够的准确性和灵活性。这部分逻辑我会在第 4 章详细讲。3.3 内嵌 Servlet 容器应用本身就是服务器SpringBoot 默认把 Tomcat 以嵌入式方式打包进应用。也就是说你生成的 jar 包中不仅包含你的代码也包含了一个可以直接运行的 Servlet 容器。由于容器内嵌部署方式彻底改变。过去是“应用适配服务器”现在是“应用直接运行”。你可以直接在命令行执行java -jar demo.jar也可以将 jar 包丢进 Docker 容器让容器内的 JDK 来执行它。开发环境、测试环境、生产环境的差异被压缩到最小。在 SpringBoot 中Tomcat 只是默认选择如果你想用 Jetty 或 Undertow只需要在依赖上切换对应的 starter业务代码一行都不用改。这个灵活性是传统外置容器时代很难想象的事情。3.4 工程化能力配置体系、监控与统一打包SpringBoot 在去掉大量 XML 配置的同时也没有把配置能力丢掉而是换了一套更轻量的方式。它支持 application.properties 和 application.yml 两种配置文件并提供多环境 profile 机制你可以用 application-dev.yml、application-prod.yml 把不同环境的差异抽出来运行时通过参数动态切换。它还提供了 Actuator 模块允许你在生产环境查看应用健康状态、指标数据、线程状态等信息。打包方面spring-boot-maven-plugin 插件提供了统一的打包能力可以把应用打成一个可执行 jar。这个 jar 里包含所有依赖和 SpringBoot 加载器逻辑在任何有 JDK 的机器上都能直接运行。到这里我们可以总结一下Starter 解决了“依赖怎么管”自动配置解决了“Bean 怎么装配”内嵌容器解决了“应用怎么跑”工程化能力解决了“生产环境怎么用”。这四件事正是 SpringBoot 替开发者做的全部核心工作。4. 自动装配原理SpringBoot 最核心的机制第四章是整个 SpringBoot 认知的基础章节中最值得花时间去理解的部分也是面试中的高频考点。自动装配并没有用到任何黑魔法它本质上是一条清晰的执行链路。先看主启动类上的注解SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }SpringBootApplication是一个组合注解它由三个注解复合而成SpringBootConfiguration它是Configuration的衍生注解标记当前类是一个配置类。EnableAutoConfiguration开启自动装配能力这是核心中的核心。ComponentScan默认扫描当前启动类所在包及其子包下的所有 Spring 组件。自动装配的起点就是EnableAutoConfiguration。它的内部通过Import(AutoConfigurationImportSelector.class)导入了一个选择器类。这个选择器做了一件关键的事情读取 classpath 下自动配置类的列表。在 SpringBoot 2.7 之前自动配置类列表放在META-INF/spring.factories文件中在 SpringBoot 2.7 及之后的版本中则调整为META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports。文件中每一行都记录着一个自动配置类的全限定名比如RedisAutoConfiguration、DataSourceAutoConfiguration。这里真正巧妙的地方在于SpringBoot 并不会无条件加载这些配置类。每个自动配置类上都叠加了大量条件注解它们像一道道关卡运行时动态判断是否执行装配。常见的条件注解包括ConditionalOnClass检查 classpath 中是否存在指定类。ConditionalOnMissingBean检查容器中是否缺少指定 Bean。ConditionalOnProperty检查配置项是否满足条件。ConditionalOnWebApplication检查当前应用是否为 Web 应用。把这些条件注解放在一起看整个自动装配的逻辑就清晰了。我用一个实际场景来串一遍假设你在 pom.xml 中引入了 spring-boot-starter-data-redis。启动时SpringBoot 加载自动配置类列表遇到 RedisAutoConfiguration 后开始做条件判断。它检查 classpath 中是否存在 RedisTemplate、LettuceConnectionFactory 等类如果存在说明项目真的需要考虑 Redis 集成于是继续检查容器中是否已经有用户自定义的 RedisTemplate Bean。如果没有才自动创建默认的 RedisTemplate 和连接工厂。换句话说自动配置类是一份“备选装配方案”框架拿着这份方案去对照当前项目的 classpath 和容器状态匹配的才执行不匹配的直接跳过。这就像装修公司拿到一本厚厚的菜单但只按照你实际买回来的材料来决定做什么菜。如果你想查看哪些自动配置生效了可以在配置文件中加上一行debugtrue启动时日志会打印 Positive matches 和 Negative matches 两大列表。Positive matches 是已经生效的自动配置Negative matches 是因为条件不满足而未生效的配置。出现自动配置不生效问题时第一件事应该是看这两张表而不是去猜原因。如果你明确不想让某个自动配置生效也有对应的排除方式。可以在启动类注解中排除SpringBootApplication(exclude {RedisAutoConfiguration.class})也可以在配置文件中排除spring.autoconfigure.excludeorg.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration自动装配原理的技术链路可以这样归纳SpringBootApplication中的EnableAutoConfiguration通过AutoConfigurationImportSelector加载自动配置类列表然后每个自动配置类通过条件注解做按需装配最终在容器中注册得到系统所需要的 Bean。我建议你在理解这条链路之后再去看具体的自动配置源码会有一种从暗箱走到明面的通透感。5. 环境准备与项目初始化在写示例之前我们先明确 SpringBoot 项目运行的环境要求。不同 SpringBoot 版本对 JDK 的要求差异很大这是新手最常踩的坑。SpringBoot 2.x最低支持 JDK 8使用 Java 8 或 11 都很常见。SpringBoot 3.x强制要求 JDK 17 及以上因为 Spring Framework 6 在 JDK 17 上构建。如果你的本机是 JDK 8去创建一个 SpringBoot 3.x 项目编译阶段就会直接报错。所以创建项目之前一定要先确认自己的 JDK 版本这与选择 SpringBoot 版本是强绑定的。建议的前置环境JDK 8 或 JDK 17视 SpringBoot 版本而定。Maven 3.6。IDEA 或 Eclipse推荐 IDEA 社区版/旗舰版均可。不需要提前安装 Tomcat内嵌容器会解决。项目创建方式有两种。第一种是使用 Spring Initializr 网页生成项目压缩包后导入 IDE第二种直接在 IDEA 中通过“New Project - Spring Initializr”创建。如果你在访问 start.spring.io 时速度较慢可以使用国内镜像地址例如阿里云提供的 Spring Initializr 服务在 IDEA 的 Server URL 中替换即可。如果你在实际工作中已经有一个 Maven 工程手动加入 SpringBoot 的 parent 和 starter 依赖也可以。从零学习和跑通流程最省力的是通过 Spring Initializr 生成。6. 完整示例从零跑通第一个 SpringBoot 项目我们这里用一个最小可运行示例把整个流程走通。项目构建工具使用 MavenSpringBoot 版本使用 3.2.5因此 JDK 需要 17。如果你的环境是 JDK 8请将 parent 版本改为 2.7.18并将 java.version 改为 8。6.1 创建项目在 IDEA 中新建项目选择 Spring Initializr。Name 填 demoGroup 填 com.exampleLanguage 选择 JavaType 选择 MavenPackaging 选择 JarJava 版本根据你本地环境选择。依赖部分先只勾选 Spring Web。生成项目后目录结构如下demo ├── pom.xml └── src └── main ├── java │ └── com/example/demo │ ├── DemoApplication.java │ └── controller │ └── HelloController.java └── resources └── application.yml6.2 完整 pom.xml如果你没有通过 Spring Initializr 生成也可以直接使用下面的 pom.xml 手工搭建环境?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.5/version relativePath/ /parent groupIdcom.example/groupId artifactIddemo/artifactId version0.0.1-SNAPSHOT/version namedemo/name descriptionSpring Boot Demo/description properties java.version17/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency /dependencies build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId /plugin /plugins /build /project这里最关键的是引入了spring-boot-starter-parent作为 Maven parent。它会统一管理 SpringBoot 相关依赖的版本之后你在 dependencies 中写 starter 时不需要再指定 version这个细节就是 SpringBoot 依赖管理机制在 Maven 层面的体现。6.3 启动类和 Controller启动类默认已经生成内容如下package com.example.demo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }接下来创建第一个 Controller路径在src/main/java/com/example/demo/controller/HelloController.javapackage com.example.demo.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import java.util.HashMap; import java.util.Map; RestController RequestMapping(/api) public class HelloController { GetMapping(/hello) public MapString, String hello() { MapString, String result new HashMap(); result.put(message, Hello Spring Boot!); return result; } }RestController相当于Controller加ResponseBody方法的返回值会直接以 JSON 形式写出。这里返回一个 MapSpring Boot 默认集成 Jackson会自动完成 JSON 序列化。6.4 配置文件与读取配置在src/main/resources/application.yml中增加基础配置server: port: 8080 spring: application: name: demo app: name: spring-boot-demo desc: first-springboot-project为了让配置更工程化我用ConfigurationProperties方式读取 app 前缀的配置。创建配置属性类路径为src/main/java/com/example/demo/config/AppProperties.javapackage com.example.demo.config; import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.stereotype.Component; Component ConfigurationProperties(prefix app) public class AppProperties { private String name; private String desc; public String getName() { return name; } public void setName(String name) { this.name name; } public String getDesc() { return desc; } public void setDesc(String desc) { this.desc desc; } }然后修改 Controller把配置值注入并暴露接口package com.example.demo.controller; import com.example.demo.config.AppProperties; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import java.util.HashMap; import java.util.Map; RestController RequestMapping(/api) public class HelloController { private final AppProperties appProperties; public HelloController(AppProperties appProperties) { this.appProperties appProperties; } GetMapping(/hello) public MapString, String hello() { MapString, String result new HashMap(); result.put(message, Hello Spring Boot!); return result; } GetMapping(/config) public MapString, String config() { MapString, String result new HashMap(); result.put(appName, appProperties.getName()); result.put(appDesc, appProperties.getDesc()); return result; } }SpringBoot 的构造器注入已经非常成熟这里的 Controller 使用构造器注入AppProperties代码简洁且易于测试。相比Value(${app.name})的散落写法ConfigurationProperties把相关配置集中到一个强类型对象中适合配置项较多的场景这也是实际项目推荐的用法。6.5 运行与验证运行方式有两种第一种在 IDEA 中直接运行DemoApplication的 main 方法。启动后控制台会出现 Spring Boot 的启动 Banner并打印内嵌 Tomcat 的监听端口。第二种使用 Maven 命令运行mvn spring-boot:run启动成功后在浏览器访问http://localhost:8080/api/hello预期返回{message:Hello Spring Boot!}再访问http://localhost:8080/api/config预期返回的是 application.yml 中配置的内容{appDesc:first-springboot-project,appName:spring-boot-demo}如果你能看到这两个接口返回 JSON说明你的第一个 SpringBoot 项目已经完全跑通了。这时候项目内部发生了什么SpringBoot 发现你引入了 spring-boot-starter-web自动配置了内嵌 Tomcat、Spring MVC、Jackson 等组件它扫描到启动类包下的 Component注册了 Controller 和配置属性类它还根据 application.yml 中的内容绑定了配置对象。整个过程没有任何外部 Tomcat、没有 web.xml、没有任何 Spring XML 文件。7. 进阶实践多环境配置、打包与 Docker 部署项目跑通之后下一步是把工程化实践中绕不开的几件事搞清楚。多环境配置是真实项目的硬需求。开发、测试、生产三套环境不可能用同一套数据库地址和日志级别。SpringBoot 的 profile 机制可以这样组织在src/main/resources下创建三个文件application.yml 作为主配置只放公共配置spring: profiles: active: devapplication-dev.ymlserver: port: 8080 app: name: spring-boot-demo desc: dev-environmentapplication-prod.ymlserver: port: 8080 app: name: spring-boot-demo desc: prod-environment启动时如果不加参数默认激活 dev profile。生产环境启动时可以通过命令行参数覆盖java -jar demo-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod也可以使用环境变量方式export SPRING_PROFILES_ACTIVEprod java -jar demo-0.0.1-SNAPSHOT.jarMaven 打包很简单进入项目根目录执行mvn clean package打包成功后在 target 目录下会生成demo-0.0.1-SNAPSHOT.jar。这个 jar 是 SpringBoot 的可执行 jar里面包含所有依赖和内嵌 Tomcat。部署时只需要把 jar 拷贝到目标机器保证装有对应版本的 JDK直接运行即可。如果项目用 Docker 部署可以编写如下 DockerfileFROM openjdk:17-jdk-slim LABEL authorsyour-name WORKDIR /app COPY target/demo-0.0.1-SNAPSHOT.jar /app/app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]构建命令docker build -t springboot-demo:1.0 .运行命令docker run -d -p 8080:8080 --name demo springboot-demo:1.0需要注意这里使用的是 JDK 17 基础镜像因为我们的 SpringBoot 版本是 3.2.5。如果你因为本机只有 JDK 8 而选择了 SpringBoot 2.7.x那么基础镜像应切换为openjdk:8-jdk-alpine否则镜像运行时同样会出现版本不兼容问题。生产部署还有一个容易被忽略的点容器内 SpringBoot 的配置注入。通常不建议把数据库密码、密钥等敏感配置直接写在 application-prod.yml 里更推荐通过环境变量注入例如spring: datasource: url: ${DB_URL} username: ${DB_USERNAME} password: ${DB_PASSWORD}这样配置文件只保留占位符真实值由容器平台在运行时注入减小配置泄露风险。涉及生产环境变更时也建议先在测试环境用同一套镜像验证再逐步切换流量。8. 常见问题与排查方法SpringBoot 项目本身的启动链路很短但新手在实际操作中仍然会遇到不少问题。下面的表格汇总了几类高频问题按“现象 - 原因 - 排查 - 解决”整理可以直接对照使用。问题现象可能原因排查方式解决方案启动报错 Web server failed to start提示 Port 8080 was already in use本地端口被其他进程占用在命令行执行lsof -i:8080或netstat -ano | findstr 8080查看占用进程关闭占用端口进程或修改server.port配置为其他端口创建 SpringBoot 3.x 项目后编译报错提示无效的目标发行版JDK 版本低于 17执行java -version确认 JDK 版本升级到 JDK 17或将 SpringBoot parent 版本降为 2.7.x从 Spring Initializr 下载或创建项目时长时间卡住网络无法稳定访问 start.spring.io查看 IDEA 日志或浏览器下载链接将 Server URL 切换为阿里云 Spring Initializr 镜像启动后请求接口返回 404启动类位置和 Controller 不在同一包路径下检查 ComponentScan 扫描范围保持 Controller 位于启动类的子包内application.yml 不自动提示属性IDE 未识别配置元数据或依赖未导入检查是否引入了 spring-boot-configuration-processor引入配置处理器依赖并在 IDEA 中刷新 Maven 索引修改 application.yml 后配置没生效应用未重启或 profile 未切换确认启动日志中 Active profile 和加载的配置文件重启应用指定正确的--spring.profiles.active自动配置没有生效条件注解判断不满足在配置中开启debugtrue查看 Positive/Negative matches按缺失条件补齐依赖或配置项Eclipse 中集成 SpringBoot 时依赖一直 downloadingMaven 仓库下载速度慢或镜像问题检查 Maven 配置文件 settings.xml 中的 mirror配置阿里云 Maven 镜像仓库这组问题里第一类“端口被占用”和第三类“创建项目卡住”是使用内嵌容器和在线初始化后的必然结果。理解它的原理后再排查就不会觉得陌生。实际上SpringBoot 的 log 输出非常友好绝大多数启动失败都会明确指向启动链路的具体位置。9. 最佳实践与学习路线建议文章写到这里SpringBoot 的核心认知框架已经搭建完整。最后我想分享几条工程实践建议这是我在实际项目中最深刻的体会。第一版本选型要先行。新项目优先选择当前稳定版本的 SpringBoot 3.x但前提是团队 JDK 版本已经支持 17。如果团队还在维护老项目不要轻易升级大版本SpringBoot 2.x 到 3.x 的升级涉及 Jakarta EE、javax 到 jakarta 包名迁移等兼容性改动成本不比想象中低。第二不要为了“省事”一次引入太多 starter。每多一个 starter自动配置就会多一批候选装配项虽然条件注解保证了按需装配但依赖体积和应用启动复杂度也会增加。建议按真实需求引入并定期用mvn dependency:tree检查依赖树。第三配置尽量集中并且类型安全。散落的Value在配置项多的时候很难维护建议对业务配置使用ConfigurationProperties封装成对象。配置项命名统一使用 kebab-case例如app.max-file-size。第四排除自动配置之前要三思。当你发现某个自动配置的行为不符合预期时第一反应不应该是 exclude 它而是先确认它的生效条件、当前 classpath 状态、以及是否可以通过显式声明一个 Bean 来覆盖默认行为。盲目 exclude 可能导致其他依赖链路断裂。第五生产环境开启 Actuator 时注意端点暴露范围。Actuator 的 health 端点很有用但不要把所有端点都无限制暴露到公网。实际部署时建议通过management.endpoints.web.exposure.includehealth,info只暴露基础端点并配合认证机制做访问控制。第六如果你正在准备 SpringBoot 面试不要只背结论。自动装配原理、条件注解、Starter 机制、内嵌容器、配置加载顺序、事务失效场景、循环依赖这七个方向基本覆盖了大部分高频考点但每个方向都需要能画出链路、讲出原因、举出例子才算真正掌握。本文是 SpringBoot 系列的第一节核心目标是把“它是什么、它做了什么、它是怎么做到的、怎么快速跑起来”这条主线打通。你在读完后建议做两件事第一按照第 5、6、7 章的内容手写一个最小项目并尝试切换 profile、打包、用 Docker 运行第二回来看第 4 章的自动装配链路用 IDEA 的 debug 功能跟着 AutoConfigurationImportSelector 走一遍源码亲眼看看自动配置类是怎么被加载进来的。等这两步都做完了自动装配原理对你来说就不再是面试题而是一种你已经内化的工程直觉。