Spring Boot 是基于 Spring Framework 开发的快速开发脚手架，核心理念是「约定优于配置（Convention Over Configuration）」，通过自动配置、起步依赖等特性，简化 Spring 应用的搭建、开发、部署流程，无需手动编写繁琐的 XML 配置，让开发者专注于业务逻辑实现。本文将从核心原理、核心特性、实战要点三个维度，全面解析 Spring Boot 核心知识点，并详细对比 1.x、2.x、3.x 三个主要版本的具体区别，兼顾深度（底层原理、源码级细节）与广度（应用场景、生态扩展）。
一、Spring Boot 核心知识点（深度+广度）
1.1 核心设计理念
Spring Boot 的所有特性均围绕「简化开发、降低复杂度、提升效率」展开，核心设计理念有3个，是理解其所有功能的基础：
- 约定优于配置（Convention Over Configuration） ：Spring Boot 预设了一套合理的默认配置（如默认端口8080、默认数据源配置、默认包扫描规则），开发者无需手动配置，仅在需要自定义时修改相关配置，大幅减少配置工作量。例如，引入
spring-boot-starter-web后，自动配置 Tomcat、DispatcherServlet 等 Web 核心组件，无需手动注册。 - 自动配置（Auto Configuration） ：Spring Boot 会根据类路径下的依赖、配置文件等信息，自动初始化 Bean、配置组件，实现「按需加载」。例如，类路径下存在
mysql-connector-java依赖时，自动配置数据源相关 Bean；存在spring-boot-starter-data-redis依赖时，自动配置 RedisTemplate 等组件，核心是通过条件注解实现灵活的配置加载。 - 嵌入式容器（Embedded Container） ：内置 Tomcat、Jetty、Undertow 等 Web 容器，无需单独部署 WAR 包到外部容器，直接通过 JAR 包即可启动应用，简化部署流程，提升开发、测试效率，也是 Spring Boot 实现「一键启动」的核心支撑。
1.2 核心底层原理（深度解析）
Spring Boot 并非对 Spring 的替代，而是在 Spring Framework 基础上进行封装，核心底层依赖 Spring IoC、AOP 特性，同时新增了自动配置、起步依赖等核心机制，以下是3个核心原理的深度拆解：
1.2.1 自动配置原理（Spring Boot 灵魂）
自动配置是 Spring Boot 最核心的功能，其底层实现依赖「注解驱动 + 条件判断 + 配置加载」，完整流程如下（源码级简化）：
-
入口注解触发：Spring Boot 应用的入口是带有
@SpringBootApplication注解的主类，该注解是一个组合注解，核心包含3个注解，共同触发自动配置机制：@SpringBootConfiguration：本质是@Configuration的特殊形式，标识当前类是配置类，允许在类中通过@Bean注解注册组件。@ComponentScan：自动扫描当前类所在包及其子包下的@Component、@Service、@Controller等注解，将其注册到 IoC 容器中。@EnableAutoConfiguration：开启自动配置的核心注解，通过@Import(AutoConfigurationImportSelector.class)导入自动配置选择器，触发自动配置类的加载。
-
自动配置类加载：
AutoConfigurationImportSelector类通过SpringFactoriesLoader加载类路径下META-INF/spring.factories（1.x、2.x）或META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（3.x）文件中注册的自动配置类（如WebMvcAutoConfiguration、DataSourceAutoConfiguration）。 -
条件过滤：自动配置类通过
@Conditional系列注解（如@ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty）进行条件判断，只有满足条件的自动配置类才会生效。例如，WebMvcAutoConfiguration会通过@ConditionalOnWebApplication注解，仅在 Web 应用中生效；DataSourceAutoConfiguration会通过@ConditionalOnClass(DataSource.class)注解，仅在类路径存在 DataSource 类时生效。 -
配置绑定：自动配置类会读取配置文件（
application.properties/application.yml）中的参数，通过@ConfigurationProperties注解绑定到对应的配置类中，实现配置的灵活定制。例如，ServerProperties类绑定server.port、server.servlet.context-path等配置，DataSourceProperties类绑定数据库相关配置。
核心关键点：自动配置的本质是「Spring IoC 容器的Bean注册 + 条件过滤」，默认配置可通过自定义配置文件、自定义配置类覆盖，实现「约定优先、自定义可选」的灵活机制。
1.2.2 起步依赖原理（Starter）
起步依赖（Starter）是 Spring Boot 简化依赖管理的核心机制，本质是「Maven/Gradle 依赖描述文件」，通过打包一组相关的依赖库并提供默认配置，让开发者无需手动引入多个零散依赖，就能快速集成某类功能，核心价值的是简化依赖引入、避免版本冲突、支持自动配置。
核心原理与细节：
- 命名规范：官方 Starter 命名遵循
spring-boot-starter-xxx（如spring-boot-starter-web、spring-boot-starter-jdbc），第三方 Starter 命名通常遵循xxx-spring-boot-starter（如mybatis-spring-boot-starter）。 - 底层实现：Starter 本身不包含业务代码，而是在其
pom.xml中声明了功能所需的所有核心依赖和传递依赖，Spring Boot 通过父工程spring-boot-dependencies统一管理所有 Starter 的依赖版本，避免版本冲突。例如，spring-boot-starter-web的pom.xml会自动引入 Spring MVC、嵌入式 Tomcat、Jackson JSON 解析器等依赖，无需开发者手动逐个添加。 - 自动配置关联：Starter 通常会关联一个或多个自动配置类，这些配置类通过
spring.factories（1.x、2.x）或AutoConfiguration.imports（3.x）文件注册，当引入 Starter 后，自动配置类会自动生效，完成组件的初始化配置。例如，引入spring-boot-starter-web后，WebMvcAutoConfiguration会自动生效，配置 Tomcat、DispatcherServlet 等核心 Web 组件。 - 自定义 Starter：开发者可根据业务需求自定义 Starter，核心步骤是：创建 Maven 项目，在
pom.xml中引入所需依赖；编写自动配置类，通过条件注解控制生效时机；编写spring.factories或AutoConfiguration.imports文件，注册自动配置类；打包发布，供其他项目引入复用。
1.2.3 嵌入式容器原理
Spring Boot 内置 Tomcat（默认）、Jetty、Undertow 三种 Web 容器，无需外部部署，核心原理是「将容器集成到应用中，通过代码启动容器」，具体流程：
- 依赖加载：引入
spring-boot-starter-web时，默认引入spring-boot-starter-tomcat依赖（Tomcat 容器），若需切换容器，可排除 Tomcat 依赖，引入 Jetty 或 Undertow 依赖。 - 容器初始化：Spring Boot 启动时，通过
EmbeddedWebApplicationContext初始化嵌入式容器，加载容器配置（如端口、上下文路径、线程池参数），这些配置可通过application.yml自定义（如server.port=8081）。 - 应用部署：容器初始化完成后，将 Spring 应用上下文关联到容器中，监听指定端口，接收 HTTP 请求，实现「一键启动」。
核心优势：简化部署流程，无需安装外部容器；支持容器灵活切换，适配不同性能需求（如 Undertow 性能优于 Tomcat，适合高并发场景）。
1.3 核心特性（广度覆盖）
Spring Boot 的核心特性围绕「简化开发、提升效率、增强扩展性」展开，涵盖开发、测试、部署全流程，以下是常用核心特性的详细解析：
1.3.1 外部化配置
外部化配置是 Spring Boot 实现「配置与代码分离」的核心特性，支持多种配置方式，优先级从高到低排序（后加载的配置会覆盖先加载的配置）：
- 命令行参数：启动应用时通过
--server.port=8081等参数指定配置，优先级最高。 - 环境变量：系统环境变量（如
SPRING_SERVER_PORT=8081），适配不同环境的配置隔离。 - 配置文件：
application.yml（推荐，语法简洁）、application.properties，支持多环境配置（如application-dev.yml、application-prod.yml），通过spring.profiles.active=dev指定激活的环境。 - 配置中心：集成 Spring Cloud Config、Nacos 等配置中心，实现分布式环境下的配置统一管理、动态刷新（适用于微服务场景）。
核心注解：@ConfigurationProperties（批量绑定配置文件参数到 Java 类）、@Value（单个注入配置参数，支持 SpEL 表达式），例如通过 @ConfigurationProperties(prefix = "spring.datasource") 可将数据库配置批量绑定到 DataSourceProperties 类中。
1.3.2 Spring Boot Starter 生态
Starter 是 Spring Boot 生态的核心，官方提供了大量 Starter，覆盖 Web 开发、数据访问、安全、监控等常见场景，第三方也提供了丰富的 Starter（如 MyBatis、Redis、RabbitMQ 等），常用官方 Starter 如下：
spring-boot-starter：核心 Starter，包含 Spring Boot 核心功能（自动配置、日志、YAML 解析等），所有其他 Starter 都依赖此 Starter。spring-boot-starter-web：Web 开发 Starter，集成 Spring MVC、嵌入式 Tomcat、Jackson 等，用于快速开发 Web 应用。spring-boot-starter-data-jpa：数据访问 Starter，集成 Spring Data JPA、Hibernate，简化数据库操作。spring-boot-starter-jdbc：JDBC Starter，集成 Spring JDBC、数据源（默认 HikariCP，2.x 及以上），用于原生 JDBC 开发。spring-boot-starter-redis：Redis Starter，集成 Spring Data Redis、Redis 客户端（默认 Lettuce，2.x 及以上），简化 Redis 操作。spring-boot-starter-security：安全 Starter，集成 Spring Security，实现身份认证、权限控制。spring-boot-starter-actuator：监控 Starter，提供应用健康检查、指标监控、接口调用统计等功能，用于应用运维监控。
1.3.3 监控与运维（Actuator）
Spring Boot Actuator 是用于应用监控和运维的核心组件，通过暴露 HTTP 端点，提供应用的运行状态、指标统计、健康检查等功能，帮助开发者快速定位问题，核心特性：
-
核心端点：
/actuator/health：应用健康检查，返回应用是否正常运行，支持自定义健康检查逻辑（如数据库连接、Redis 连接检查）。/actuator/info：应用信息，可配置应用名称、版本、作者等信息。/actuator/metrics：应用指标，如 JVM 内存使用、CPU 使用率、HTTP 请求数、接口响应时间等。/actuator/loggers：日志管理，可动态修改日志级别（无需重启应用）。/actuator/shutdown：应用关闭（默认禁用，需手动开启），支持优雅关闭应用。
-
扩展能力：可集成 Micrometer（指标收集工具），对接 Prometheus、Grafana 等监控平台，实现指标可视化、告警等功能；3.x 版本深度集成 Micrometer Tracing，支持分布式追踪（如 Brave、OpenTelemetry），适配微服务监控场景。
1.3.4 测试支持
Spring Boot 内置完善的测试支持，通过 spring-boot-starter-test Starter，集成 JUnit、Mockito、Spring Test 等测试框架，支持单元测试、集成测试、Mock 测试，核心注解：
@SpringBootTest：启动 Spring 应用上下文，用于集成测试（如测试 Service、Dao 层，自动注入依赖）。@WebMvcTest：仅启动 Web 层上下文，用于测试 Controller 层，无需启动完整应用。@MockBean：Mock 容器中的 Bean，用于隔离依赖（如 Mock Dao 层，避免依赖数据库）。@TestPropertySource：指定测试环境的配置文件，用于测试环境与生产环境的配置隔离。
1.3.5 其他核心特性
- 热部署：通过
spring-boot-devtools依赖，实现代码修改后自动重启应用，提升开发效率（开发环境使用，生产环境禁用）；3.x 版本对 DevTools 进行了改进，支持热重载（LiveReload）和更高效的自动重启机制。 - 异步处理：通过
@Async注解标记方法为异步方法，配合@EnableAsync注解开启异步支持，实现异步调用（如异步发送邮件、异步处理日志），提升应用响应速度。 - 定时任务：通过
@Scheduled注解标记定时任务方法，配合@EnableScheduling注解开启定时任务支持，支持 cron 表达式、固定延迟、固定速率等定时方式。 - 安全支持：集成 Spring Security，提供身份认证、权限控制、CSRF 防护等功能，可快速实现用户登录、接口权限校验；3.x 版本集成 Spring Security 6.x，默认启用更强的安全策略，支持 OAuth2 和 JWT 的更简洁配置。
- 响应式编程：2.x 版本引入 WebFlux（基于 Reactor 框架），支持响应式编程，适用于高并发、IO 密集型场景，与传统的 Spring MVC（同步阻塞）形成互补；3.x 版本进一步优化了响应式编程的支持，适配 Jakarta EE 规范。
1.4 实战核心要点（深度+实战）
结合实际开发场景，梳理 Spring Boot 实战中的核心要点，解决开发中常见的问题，提升开发效率和应用质量：
1.4.1 自动配置的自定义覆盖
Spring Boot 的默认自动配置可通过以下3种方式覆盖，满足自定义需求：
- 自定义配置文件：在
application.yml/application.properties中修改默认配置（如server.port=8081、spring.datasource.url=jdbc:mysql://localhost:3306/test）。 - 自定义配置类：编写带有
@Configuration注解的配置类，注册自定义 Bean，覆盖默认自动配置的 Bean（如自定义数据源、自定义 RedisTemplate）；若需完全禁用某个自动配置类，可通过@SpringBootApplication(exclude = 自动配置类.class)排除（如exclude = DataSourceAutoConfiguration.class）。 - 自定义 Starter：通过自定义 Starter，封装项目通用配置（如公司内部的数据库配置、缓存配置），实现配置复用，减少重复开发。
1.4.2 依赖管理与版本控制
- 父工程依赖：Spring Boot 项目通常继承
spring-boot-starter-parent父工程，该父工程统一管理所有 Starter 的依赖版本，避免版本冲突；若项目无法继承父工程，可通过dependencyManagement标签引入spring-boot-dependencies，手动管理版本。 - 依赖排除：当引入的 Starter 包含不需要的依赖时，可通过
exclusions标签排除（如排除 Tomcat 依赖，切换为 Jetty 容器）。 - 版本升级：升级 Spring Boot 版本时，需注意依赖的兼容性（如 Spring Boot 3.x 依赖 Spring Framework 6.x，需升级相关依赖到对应版本）；可通过
mvn dependency:tree分析依赖树，排查版本冲突问题。
1.4.3 应用部署与优化
-
部署方式：
- JAR 包部署（推荐）：通过
mvn package打包为 JAR 包，直接通过java -jar xxx.jar启动，无需外部容器，适配云原生部署（如 Docker、K8s）。 - WAR 包部署：修改打包方式为 WAR，排除内置容器依赖，部署到外部 Tomcat、Jetty 容器（适用于传统部署场景）。
- 原生镜像部署（3.x 新增）：通过 GraalVM 将应用编译为原生可执行文件，实现毫秒级启动、内存占用降低 50%+，适合 Serverless、FaaS 场景，通过
native-maven-plugin可直接构建原生镜像。
- JAR 包部署（推荐）：通过
-
性能优化：
- 容器优化：切换为 Undertow 容器，提升高并发场景下的性能；优化容器线程池参数（如 Tomcat 的最大线程数、队列大小）。
- 数据源优化：配置合理的连接池参数（如 HikariCP 的最大连接数、连接超时时间），避免连接池不足或浪费。
- JVM 优化：设置合理的 JVM 内存参数（如堆内存、元空间大小），避免内存溢出、GC 频繁。
- AOT 编译（3.x 新增）：引入 AOT（Ahead-of-Time）编译，将反射、代理等运行时行为提前编译为静态代码，提升应用启动速度和运行性能，通过
@ImportRuntimeHints注解显式声明运行时依赖。
1.4.4 常见问题解决方案
- 自动配置失效：检查是否引入对应的 Starter、是否排除了自动配置类、是否满足自动配置的条件（如类路径是否存在对应依赖）。
- 依赖冲突：通过
mvn dependency:tree分析依赖树，找到冲突的依赖，通过exclusions排除冲突依赖，或指定依赖版本。 - 端口冲突：修改
server.port配置，或停止占用该端口的进程。 - 配置文件不生效：检查配置文件路径是否正确（默认放在
src/main/resources下）、配置参数是否正确（如语法错误、前缀错误）、是否激活了对应的环境配置。 - 同一类中方法调用 AOP 增强失效：由于 Spring AOP 基于动态代理，同一类中方法调用时，调用的是目标对象自身的方法，而非代理对象的方法，可通过自注入（配合
@Lazy注解）或 ApplicationContext 获取代理对象解决。
二、Spring Boot 1.x、2.x、3.x 具体区别（重点拆解）
Spring Boot 自 2014 年发布 1.0 版本以来，经历了 1.x、2.x、3.x 三个主要大版本的迭代，每个版本都伴随着底层依赖升级、核心特性新增、API 调整，以下从「底层依赖、核心特性、API 变更、适用场景」四个维度，详细对比三个版本的具体区别，兼顾实用性和深度，帮助开发者选择合适的版本：
2.1 整体版本迭代概览
| 版本系列 | 发布时间范围 | 基于 Spring Framework 版本 | 最低 Java 版本要求 | 最高支持 Java 版本 | 核心定位 | 现状 |
|---|---|---|---|---|---|---|
| 1.x | 2014 – 2018 | 4.x | Java 6/7 | Java 8 | 快速启动、简化配置，奠定「约定优于配置」的核心理念，实现 Spring 应用的快速搭建 | 已停止维护（1.5.x 于 2019 年 8 月 EOL），不建议新项目使用，仅存量系统维护 |
| 2.x | 2018 – 2023 | 5.x | Java 8 | Java 19（2.7+） | 性能优化、响应式支持、云原生准备，完善生态，提升稳定性和扩展性 | 2.7.x 是最后一个 2.x 版本，2023 年 11 月停止 OSS 支持（商业支持延续），存量系统广泛使用，新项目不推荐 |
| 3.x | 2022 – 至今 | 6.x | Java 17（LTS） | Java 21+（推荐） | 现代化重构，拥抱 Jakarta EE、GraalVM、Java 17+，优化性能和可观测性，适配云原生和微服务 | 当前主流版本，官方持续维护，新项目首选，支持更多现代化特性 |
2.2 核心维度具体区别（深度拆解）
2.2.1 底层依赖与环境要求
-
Spring Framework 依赖：
- 1.x：基于 Spring Framework 4.x，依赖 Java 6/7，兼容 Java 8，不支持 Java 9+ 新特性。
- 2.x：基于 Spring Framework 5.x，依赖 Java 8（最低），支持 Java 9-19，引入了 Spring 5.x 的核心特性（如响应式编程、函数式编程、注解驱动开发增强）。
- 3.x：基于 Spring Framework 6.x，依赖 Java 17（最低，强制要求），推荐 Java 21，利用 Java 17+ 新特性（如 record 不可变类、sealed class 密封类、pattern matching 模式匹配）优化框架内部逻辑，不兼容 Java 8/11 等旧版本。
-
Java EE / Jakarta EE 依赖：
- 1.x / 2.x：依赖 Java EE（如 Servlet 3.0+、JPA 2.0+），包名使用
javax.*（如javax.servlet、javax.persistence）。 - 3.x：全面迁移到 Jakarta EE 9+，包名从
javax.*替换为jakarta.*（如jakarta.servlet、jakarta.persistence），所有涉及 Java EE 的依赖（如 Hibernate、Spring Data JPA）需升级到支持 Jakarta EE 9+ 的版本，这是 3.x 最具颠覆性的变更之一。
- 1.x / 2.x：依赖 Java EE（如 Servlet 3.0+、JPA 2.0+），包名使用
-
嵌入式容器版本：
- 1.x：默认 Tomcat 7/8，支持 Jetty 8/9，不支持 Undertow。
- 2.x：默认 Tomcat 8.5+，支持 Jetty 9+、Undertow 2.x，新增 Undertow 容器支持，提供更好的性能。
- 3.x：默认 Tomcat 10+（适配 Jakarta EE 9+），支持 Jetty 12+、Undertow 2.3+，容器版本全面升级，适配新的规范和特性，3.2+ 版本支持 Java 21 虚拟线程，提升高并发吞吐能力。
2.2.2 核心特性差异
-
自动配置机制：
- 1.x：自动配置机制初步完善，通过
spring.factories文件注册自动配置类，条件注解种类较少，配置灵活性有限。 - 2.x：增强自动配置机制，新增更多
@Conditional系列注解（如@ConditionalOnResource、@ConditionalOnWebApplication），支持自动配置类的排序（@AutoConfigureBefore/@AutoConfigureAfter），优化配置绑定逻辑，支持宽松绑定（如驼峰、下划线、横杠格式互通）。 - 3.x：重构自动配置机制，用
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件替代传统的spring.factories文件，支持多文件合并，避免配置冲突；移除@ConfigurationProperties的宽松绑定，仅支持 kebab-case 格式（如下划线格式不再兼容）；增强自动配置的性能，减少启动时间。
- 1.x：自动配置机制初步完善，通过
-
起步依赖（Starter） ：
- 1.x：提供核心 Starter（如
spring-boot-starter-web、spring-boot-starter-jdbc），但 Starter 种类较少，第三方 Starter 生态不完善。 - 2.x：扩展 Starter 生态，新增大量官方 Starter（如
spring-boot-starter-webflux、spring-boot-starter-actuator增强版），第三方 Starter 快速发展；默认数据源从 Tomcat JDBC 切换为 HikariCP（性能更优）；Redis 客户端从 Jedis 切换为 Lettuce（默认）。 - 3.x：优化 Starter 依赖管理，移除部分过时的 Starter（如
spring-boot-starter-velocity）；新增spring-boot-starter-native，官方支持 GraalVM 原生镜像构建；Starter 依赖的版本全面升级，适配 Jakarta EE 9+ 和 Spring Framework 6.x；简化自定义 Starter 的开发流程，支持自动配置类的批量导入。
- 1.x：提供核心 Starter（如
-
响应式编程：
- 1.x：不支持响应式编程，仅支持传统的同步阻塞编程（Spring MVC）。
- 2.x：新增 WebFlux 模块（基于 Reactor 框架），支持响应式编程，适配高并发、IO 密集型场景；支持响应式数据源（如 R2DBC）、响应式 Redis 等，与 Spring MVC 形成互补；引入 Micrometer 作为统一指标监控门面，替代 Dropwizard Metrics。
- 3.x：优化 WebFlux 性能，完善响应式生态，支持更多响应式组件；WebFlux 适配 Jakarta EE 9+，与 Spring MVC 共享更多核心组件，提升开发一致性；增强响应式编程的调试和监控能力，集成 Micrometer Tracing 实现分布式追踪。
-
监控与运维（Actuator） ：
- 1.x：Actuator 功能较弱，仅提供基础的健康检查（
/health）、应用信息（/info）端点，无安全隔离，监控指标较少。 - 2.x：重构 Actuator，端点路径统一为
/actuator/xxx；支持细粒度安全控制（通过management.endpoints.web.exposure.include指定暴露的端点）；新增大量监控端点（如/actuator/metrics、/actuator/loggers）；支持自定义健康检查逻辑；集成 Micrometer，支持对接 Prometheus、Grafana 等监控平台。 - 3.x：增强 Actuator 的可观测性，深度集成 Micrometer 2.0，支持更丰富的指标采集（如 JVM、HTTP 请求、数据库连接池）；默认暴露
/actuator/health、/actuator/info端点，其他端点需显式开启；支持指标的动态配置和过滤；新增分布式追踪支持，适配微服务监控场景；优化 Actuator 的性能，减少对应用的影响。
- 1.x：Actuator 功能较弱，仅提供基础的健康检查（
-
其他核心特性差异：
- 1.x：不支持 Spring Native（原生镜像）、函数式 Web 开发、虚拟线程；日志管理依赖 Commons Logging。
- 2.x：支持 Spring Native 实验性特性（需额外引入 Spring Native 项目）；支持函数式 Web 开发（基于 Spring 5.x 的函数式编程特性）；支持 Kotlin、Lombok 深度集成；支持 RSocket（2.2+）；日志管理逐步转向 SLF4J，减少对 Commons Logging 的依赖。
- 3.x：官方支持 GraalVM 原生镜像（无需额外插件），通过
native-maven-plugin直接构建原生可执行文件，实现毫秒级启动；全面支持 Java 9+ 的模块系统（JPMS），允许通过module-info.java显式声明模块依赖；默认使用 Java 11+ 的java.net.http.HttpClient，替代旧版的 Apache HttpClient；移除过时技术（如 Velocity 模板引擎、Guava 缓存自动配置、Commons Logging）；3.2+ 版本支持 Java 21 虚拟线程，与嵌入式容器协同，提升高并发吞吐能力；优化 DevTools 热部署功能，支持 LiveReload 和更高效的自动重启。
2.2.3 API 与配置变更（破坏性变更）
三个版本存在较多 API 和配置的破坏性变更，升级版本时需重点关注，避免代码报错：
-
1.x → 2.x 破坏性变更：
- 配置参数变更：如
server.context-path改为server.servlet.context-path；spring.datasource.tomcat.*改为spring.datasource.hikari.*（默认数据源切换为 HikariCP）；Actuator 配置参数统一前缀为management。 - API 废弃与替换：如
SpringApplication.run()方法的参数变更；@EnableAutoConfiguration的部分属性废弃；Spring Data JPA 的部分 API 调整，Hibernate 升级到 5.2+，移除Session.get()的String重载；Thymeleaf 升级到 3.x，模板语法有变化。 - 依赖移除：移除对 Spring Boot 1.x 专属 Starter 的支持；移除对 Java 6/7 的支持。
- 配置参数变更：如
-
2.x → 3.x 破坏性变更（影响最大） ：
- 包名变更：所有
javax.*包名替换为jakarta.*，如javax.servlet.http.HttpServletRequest改为jakarta.servlet.http.HttpServletRequest；javax.persistence.Entity改为jakarta.persistence.Entity，所有涉及 Java EE 的代码和依赖都需修改。 - API 废弃与移除：移除 Spring Boot 2.x 中废弃的 API（如
SpringApplicationBuilder的部分方法）；Spring Security 6.x 废弃大量旧 API，如WebSecurityConfigurerAdapter被移除，需使用函数式方式配置安全规则；Spring Data JPA 升级到 3.x，部分 API 不兼容。 - 配置参数变更：移除
@ConfigurationProperties的宽松绑定，仅支持 kebab-case 格式（如spring.datasource.url不可写为spring.datasource.url以外的格式）；Actuator 部分端点名称和配置参数变更；自动配置类的注册方式变更（从spring.factories改为AutoConfiguration.imports）。 - 依赖升级：Spring Framework 升级到 6.x，所有依赖 Spring Framework 的组件需同步升级；Hibernate 升级到 6.x，JPA 规范升级到 3.0+；Redis 客户端 Lettuce 升级到 6.x+，Jedis 支持需手动引入依赖；其他第三方依赖（如 MyBatis、Spring Cloud）需升级到支持 Spring Boot 3.x 的版本。
- 包名变更：所有
2.2.4 适用场景差异
-
1.x：
- 适用场景：仅用于存量系统维护，这些系统基于 Java 6/7，无法升级到更高版本的 Java 和 Spring Boot；无需响应式编程、高级监控等特性，业务逻辑简单。
- 不适用场景：新项目开发、需要高并发、响应式编程、云原生部署的场景；需要使用 Java 8+ 新特性的场景。
-
2.x：
- 适用场景：存量系统（基于 Java 8），无法升级到 Java 17；需要响应式编程、高级监控、微服务支持，但不需要 GraalVM 原生镜像、Jakarta EE 9+ 等新特性；团队对 Java 17 不熟悉，需要过渡性版本。
- 不适用场景：新项目开发（推荐 3.x）；需要使用 Java 17+ 新特性、GraalVM 原生镜像、Jakarta EE 9+ 规范的场景；对性能要求极高，需要 AOT 编译、虚拟线程等优化的场景。
-
3.x：
- 适用场景：新项目开发（首选）；基于 Java 17+，需要使用 Java 17+ 新特性（如 record、密封类）；需要 GraalVM 原生镜像、AOT 编译，追求毫秒级启动和低内存占用（如 Serverless、FaaS 场景）；需要 Jakarta EE 9+ 规范支持；微服务架构，需要完善的可观测性、分布式追踪；高并发场景，需要虚拟线程、Undertow 容器等性能优化。
- 不适用场景：系统基于 Java 8/11，无法升级到 Java 17；依赖大量未适配 Jakarta EE 9+ 的第三方组件；团队对 Java 17、Spring Framework 6.x 不熟悉，且无法投入成本学习。
2.3 版本升级建议
- 1.x → 2.x：建议直接跳过 1.x，若需升级，先升级到 1.5.x（最后一个 1.x 版本），再逐步升级到 2.7.x（最后一个 2.x 版本），重点修改配置参数、废弃 API，替换数据源为 HikariCP，适配 Spring Framework 5.x 的特性。
- 2.x → 3.x：升级前需做好充分准备，先升级 Java 版本到 17+；升级所有依赖（如 Spring Framework、Hibernate、MyBatis、Spring Security）到支持 3.x 的版本；修改代码中的
javax.*包名为jakarta.*；调整配置参数（如移除宽松绑定、修改 Actuator 配置）；重构 Spring Security 配置（替换 WebSecurityConfigurerAdapter）；测试所有功能，排查 API 不兼容问题。 - 新项目：优先选择 3.x 版本，享受 Java 17+ 新特性、GraalVM 原生镜像、AOT 编译等优势，适配云原生和微服务发展趋势；若团队对 Java 17 不熟悉，可先过渡到 2.7.x，待团队熟悉后再升级到 3.x。
三、总结
Spring Boot 的核心价值是「简化开发、提升效率、降低复杂度」，其核心知识点围绕自动配置、起步依赖、嵌入式容器三大核心机制展开，同时涵盖外部化配置、监控运维、测试支持等实战特性，兼顾深度（底层原理、源码级细节）与广度（生态扩展、应用场景）。
Spring Boot 1.x、2.x、3.x 的迭代，本质是「适配 Java 版本升级、完善生态、优化性能、拥抱现代化技术」的过程：1.x 奠定基础，2.x 完善生态和性能，3.x 实现现代化重构，适配 Jakarta EE、GraalVM、Java 17+ 等新技术，满足云原生、微服务、高并发的场景需求。
实际开发中，需根据项目的 Java 版本、业务需求、团队技术栈，选择合适的 Spring Boot 版本，同时掌握核心原理和实战要点，才能高效开发、优化 Spring Boot 应用，充分发挥其核心优势。
