Spring Boot 4 与 Spring Framework 7

• 基线要求（JDK/Jakarta）
• 升级路径
• 迁移断点

Spring Boot 4 / Spring Framework 7 基线：JDK 17+（基线，推荐更高）、Jakarta EE 11（Servlet 6.1）。升级路径：从 Boot 3.x 迁移到 Boot 4，需确认 JDK 版本、Jakarta 命名空间（已是 jakarta）、依赖库版本。主要断点：API 移除/废弃（某些 3.x 废弃的类/方法在 4 移除）；虚拟线程默认支持（Boot 4 对虚拟线程默认适配）；自动配置变化（@AutoConfiguration 机制调整）；Observability 变化（Micrometer Observation 默认开启）；依赖升级（第三方库、Servlet 6.1）。迁移需先查兼容矩阵，逐级升级，用 mvn dependency:tree 检查冲突，回归测试。

迁移断点是"API 移除 + 虚拟线程 + 自动配置 + Jakarta 11"。升级路径先查矩阵、逐级验证。核心是处理断点。

• API 版本化原生支持
• 取代自研路由
• 方案

Spring Framework 7 为 @RequestMapping 提供原生 version 参数，实现 API 版本化：@GetMapping(version = "v1") 或 @RequestMapping(headers = "X-API-Version")，Spring 根据请求的版本匹配对应 handler。原生支持取代自研版本路由：自研方案（手动解析 URL 版本、自定义路由、网关分发）需维护版本逻辑，Spring 原生支持统一了版本匹配（按版本选择 handler），减少自研代码。配合 Spring Cloud 路由：版本化可在控制器层或网关层（按版本路由）。价值：原生、统一、可维护，替代自研路由。工程上：用 Spring 原生版本参数替代自研路由，简化版本管理。

Framework 7 原生 version 参数按版本匹配 handler。取代自研路由，统一版本管理。与 Spring Cloud 路由协配合用。

• 虚拟线程默认支持
• 配置开关
• 适用边界

Spring Boot 4 对虚拟线程默认支持：spring.threads.virtual.enabled=true 时，Tomcat 等容器与框架使用虚拟线程执行请求。适用边界：虚拟线程适合"IO 密集、阻塞多"场景（大量阻塞调用可用轻量虚拟线程高并发），但不适合"CPU 密集"场景（虚拟线程不增 CPU 算力）。适用边界：阻塞 IO（数据库、HTTP、文件）多的服务适合虚拟线程；绑定平台线程的操作（原生库、synchronized 长持有、线程池依赖）需谨慎。虚拟线程下，某些依赖平台线程的组件（线程池、ThreadLocal）需适配。工程上：IO 密集用虚拟线程，CPU 密集/平台线程依赖场景慎用，评估替换。

虚拟线程默认开关 + 适用边界。IO 密集受益（高并发阻塞），CPU 密集不增算力。平台线程依赖需评估。

• RestTestClient 统一入口
• 链式 API
• 工程取舍

Spring Boot 4 的 RestTestClient 提供统一的集成测试入口，替代分别用 RestTemplate（Servlet）与 WebTestClient（WebFlux）的测试。链式 API：RestTestClient 提供链式断言（发起请求、断言响应），统一 Servlet 与响应式应用的测试方式。工程取舍：统一——一个入口测两种栈，减少测试代码差异；链式——断言简洁、可读；但——迁移现有 RestTemplate/WebTestClient 测试需改造，且抽象层可能屏蔽底层差异。取舍：新项目/统一测试策略用 RestTestClient（统一、链式），存量测试按需迁移。工程上：RestTestClient 统一测试入口，权衡迁移成本与统一收益。

RestTestClient 是"统一测试入口"。链式 API 简洁，统一 Servlet/WebFlux。取舍是迁移成本 vs 统一收益。

• 自动埋点
• 手动 vs 自动
• 边界

Spring Boot 4 默认开启 Micrometer Observation + OpenTelemetry 自动埋点：各组件（Web、DB、消息、Feign）自动生成 span/指标，无需手写埋点。手动 vs 自动边界：自动埋点——覆盖框架组件（HTTP、JDBC、消息、REST 客户端）的通用观测，无需干预；手动埋点——需要自定义观测（业务指标、自定义 span、上下文传播）时，用 Observation API 或 @Observed 手动埋点。边界：自动埋点覆盖"框架层"，手动埋点覆盖"业务层/自定义"。自动埋点不能覆盖业务特有逻辑，需手动补充。工程上：自动埋点覆盖框架，手动埋点补充业务，边界清晰。

自动埋点管框架层，手动埋点管业务层。默认自动开启，业务自定义用 Observation API。边界是"框架 vs 业务"。

• @ConfigurationProperties 绑定
• 宽松绑定
• 校验

Spring Boot 4 的 @ConfigurationProperties 绑定外部配置到强类型 Bean：@ConfigurationProperties(prefix="app") 标注类，@EnableConfigurationProperties 或 @ConfigurationPropertiesScan 注册。宽松绑定（Relaxed Binding）：属性名可用多种形式匹配（app.name、app.name、APP_NAME、app-name）——环境变量、命令行、配置文件的键名宽松匹配到属性。校验：用 @Validated + JSR-303 校验注解（@NotNull、@Min）在绑定后校验配置合法性。绑定时机：启动时绑定，配合 @RefreshScope 可刷新。工程上：@ConfigurationProperties 强类型绑定 + 宽松绑定 + 校验，保证配置正确性。

绑定是"外部配置 → 强类型对象"，宽松绑定适应多种命名，校验保证合法性。三者配合提升配置管理。

• Native Image 一等公民
• 工程价值
• 启动/内存

Spring Boot 4 对 GraalVM Native Image 的一等公民支持：Spring Boot 原生支持 Native Image（AOT 预编译、native profile、自动处理反射/代理），原生应用的工程价值：启动快（毫秒级，优于 JVM 秒级）、内存占用低（比 JVM 低）、适合无服务器/容器（冷启动快、弹性伸缩）、镜像小。工程价值：云原生友好（快速启动、资源高效）、Serverless 场景（冷启动快）、微服务资源优化。代价：AOT 编译复杂（反射/代理需配置）、构建慢、动态能力受限。工程上：Native Image 适合云原生/Serverless/启动敏感场景，权衡构建复杂度与运行时优势。

一等公民支持降低 Native 门槛。价值是启动快、内存低、云原生友好。代价是 AOT 复杂度。权衡使用。

• AOT 编译
• 边界
• 运行时能力

Spring Framework 7 与 Spring Boot 4 协同的 AOT（Ahead-of-Time）编译：启动时把 Spring 应用元数据、Bean 定义、配置提前编译为优化代码，减少启动开销。AOT 边界：AOT 处理"静态可确定的配置"（Bean 定义、配置绑定、条件），但"运行时动态行为"（反射、动态代理、运行时加载的类）不在 AOT 范围，需在运行时处理或声明（reflect-config）。边界：AOT 优化"启动期"，运行时动态能力仍需 JVM/Native 支持。Native Image 下 AOT 是必须且需手动处理反射；JVM 下 AOT 是启动优化（可选项）。工程上：理解 AOT 边界（静态可编译 vs 动态需运行时），合理配置反射/代理。

AOT 边界是"静态可编译 vs 运行时动态"。AOT 优化启动，动态能力需运行时/声明。Native 下 AOT 必须。

• JSpecify 注解
• Null-safety
• 影响

Spring 7 在 Null-safety 上从 Spring 自定义注解（@NonNull、@Nullable）迁移到 JSpecify 注解体系（org.jspecify.annotations）。影响：业务代码中标注的可空性注解需迁移到 JSpecify 注解（@NonNull/@Nullable 从 jspecify 导入）；编译期/静态分析（IDEA、Kotlin、Explicit）兼容性更好（JSpecify 是标准）；IDE 提示与 Kotlin 空安全结合更好。迁移影响：现有 spring.lang.Nullable 导入需改为 org.jspecify.annotations.Nullable；第三方库/工具对 JSpecify 支持更好。工程上：迁移到 JSpecify 注解，获得标准空安全支持，改造注解导入。

JSpecify 迁移是"注解体系标准化"。影响是注解导入与空安全工具兼容。JSpecify 标准更好。

• 模块化拆分
• 依赖体积
• 启动时间

Spring Boot 4 模块化拆分（按 starter 更细地拆 jar）：减少冗余依赖——只引入需要的模块，避免全量 starter 带来的无关依赖；影响：依赖体积减小（只打包使用的模块）、启动时间可能缩短（减少加载的类与自动配置）。但拆分也带来：版本管理更复杂（更多模块）、迁移成本（依赖调整）。模块化价值：按需引入、精简依赖、加快启动（加载更少）。工程上：用细粒度 starter 按需引入，优化依赖体积与启动时间，权衡管理复杂度。

模块化按需引入精简依赖，减小体积、加快启动。代价是版本管理复杂。权衡精简与复杂度。

• version 参数
• 版本控制
• 与 Spring Cloud 路由协作

Spring Framework 7 的 @RequestMapping(version = "v1") 实现 API 版本控制：Spring 根据请求的版本（Header/参数）匹配对应 handler 版本。与 Spring Cloud 路由协作：Spring Cloud Gateway 负责"按版本路由到服务/实例"（入口层），Spring Framework 7 的 version 参数负责"服务内按版本匹配 handler"（服务层）。协作：网关按版本路由到不同服务/实例（灰度），服务内的 version 参数匹配同版本 handler；或网关按版本路由到同一服务，服务内按 version 匹配 handler。分工：网关管"服务级版本路由"，Framework 管"方法级版本匹配"。工程上：网关版本路由 + 服务内 version 参数，分层版本控制。

协作是"网关版本路由（服务级）+ Framework version 参数（方法级）"。分层版本控制。网关路由、服务内匹配。

• 模块化 + Modulith
• Jakarta EE 11
• 迁移工作量

Spring Boot 4 模块化架构 + Spring Modulith 与 Jakarta EE 11 基线的迁移工作量评估：模块化——迁移到细粒度 starter 需调整依赖（工作量中）；Modulith——若引入模块化单体需拆分模块、定义边界（工作量中高）；Jakarta EE 11 / Servlet 6.1——容器升级（Tomcat 11）、依赖库版本、Servlet API 适配（工作量中）。整体评估：单纯升级 Boot 4 工作量中（依赖、断点、Jakarta）；叠加 Modulith 模块化工作量中高（模块拆分与边界）；依赖 Servlet API 的第三方库需适配。迁移需分步：先升级 Boot 4（依赖 + Jakarta），再按需引入 Modulith/模块化。工程上：评估依赖复杂度与模块化需求，分阶段迁移。

迁移工作量 = 依赖升级（中）+ Jakarta/容器（中）+ Modulith 模块化（中高）。分阶段迁移，按需引入模块化。

• 虚拟线程自动适配
• 阻塞 IO 边界
• 手工替换

Spring Boot 4 对虚拟线程自动适配：Tomcat 等容器、Web 框架自动使用虚拟线程执行请求。但自动适配边界：某些阻塞 IO 调用仍需手工替换——虚拟线程的收益在于"阻塞期间让出载体线程"，若阻塞调用不能释放虚拟线程（如持有 synchronized、调用平台线程池、原生库），则虚拟线程退化为阻塞平台线程。需手工替换的场景：synchronized 长持有（虚拟线程下阻塞，无法让出）、线程池依赖（Thread.sleep 阻塞可让出，但线程池任务不自动用虚拟线程）、原生库/阻塞 JDBC 驱动（某些驱动不配合虚拟线程）。工程上：自动适配覆盖 Web 请求，阻塞 IO（synchronized、线程池、特定驱动）需评估替换。

自动适配边界是"能释放虚拟线程的阻塞"。synchronized、线程池、原生库阻塞需手工处理。理解虚拟线程让出机制。

• 配置优先级
• 多来源
• 顺序

Spring Boot 4 外部化配置优先级（从高到低）：命令行参数 > 环境变量 > 应用外部配置文件（application-{profile}、application）> 应用内部配置文件（jar 内）> 默认配置。YAML 与 properties 等价（YAML 也是配置源）。优先级核心：命令行最高（应急覆盖）、环境变量次之（部署注入）、配置文件（profile 覆盖基础）、默认最低。spring.config.import 导入的配置（如 Nacos）参与优先级。理解优先级：命令行 > 环境变量 > 外部配置文件 > 内部配置文件 > 默认。工程上：按优先级管理配置，避免覆盖混乱。

优先级是"命令行 > 环境变量 > 外部文件 > 内部文件 > 默认"。profile 覆盖基础。理解多来源优先级。

• 测试切片
• @SpringBootTest
• 选择

Spring Boot 测试切片（slice test）：@WebMvcTest——只加载 Web MVC 层（Controller、过滤器），Mock 其他依赖，适合 Controller 测试；@DataJpaTest——只加载 JPA 层（Repository、实体），用内嵌数据库，适合 Repository 测试；@JsonTest、@RestClientTest 等。@SpringBootTest——加载完整应用上下文，适合集成测试（端到端）。选择：单元/切片测试（快、隔离）用测试切片（@WebMvcTest/@DataJpaTest），验证某一层；集成测试（全链路）用 @SpringBootTest。切片测试快（不加载全部），集成测试慢但完整。工程上：分层验证——切片测单层，@SpringBootTest 测集成，按需选择。

切片测试"只加载一层"（快、隔离），@SpringBootTest"加载完整上下文"（慢、完整）。按测试目标选择。

• @AutoConfiguration
• 条件注解
• 评估顺序

Spring Boot 4 的自动配置：@AutoConfiguration 注解替代旧的 @Configuration + spring.factories，通过 AutoConfiguration.imports 文件注册。自动配置类通过条件注解（@ConditionalOnClass、@ConditionalOnProperty、@ConditionalOnMissingBean 等）按条件装配。评估顺序：自动配置类的加载顺序（@AutoConfiguration 的 before/after 或 auto-configuration 列表顺序）决定条件评估顺序；条件注解按"classpath 条件、属性条件、Bean 条件"评估。@ConditionalOnMissingBean 避免重复装配（用户自定义 Bean 时自动配置不生效）。工程上：理解自动配置的注册方式与条件评估顺序，用 @ConditionalOnMissingBean 覆盖。

自动配置变化是"@AutoConfiguration + imports 文件"。条件注解按顺序评估，@ConditionalOnMissingBean 允许覆盖。理解评估顺序。

• @HttpExchange
• 替代 OpenFeign
• 价值与边界

Spring Boot 4 集成 Spring 的 @HttpExchange 接口式 HTTP 客户端：用接口 + 注解（@GetExchange、@PostExchange）声明 HTTP 调用，Spring 自动生成实现（基于 RestClient/WebClient）。工程价值：无需 OpenFeign 依赖，原生支持（Spring 生态）、与 Spring 集成好、声明式简洁。边界：@HttpExchange 是基础 HTTP 客户端，缺少 OpenFeign 的额外能力（如继承、复杂契约、丰富的配置）；负载均衡/熔断需配合 Spring Cloud LoadBalancer/CircuitBreaker。选型：简单 HTTP 调用、减少依赖用 @HttpExchange；需要 OpenFeign 生态/复杂契约用 OpenFeign。工程上：@HttpExchange 轻量替代，权衡能力边界。

@HttpExchange 是"原生接口式 HTTP 客户端"。价值轻量、无额外依赖；边界是能力较 OpenFeign 简单。按需选择。

• 优雅停机
• 流量摘除
• 配置

Spring Boot 4 的优雅停机（graceful shutdown）：server.shutdown=graceful 开启，停机时停止接收新请求，等待在途请求处理完成（spring.lifecycle.timeout-per-shutdown-phase 控制超时）。流量摘除：停机前先从注册中心摘除（Nacos 注销）、K8s readiness 探针摘除，停止新流量进入，再排空在途请求。配合：注册中心摘除（deregister）→ readiness 摘除 → 优雅停机（排空）→ 关闭资源。K8s 下用 preStop hook + readiness 探针 + graceful shutdown 超时。工程上：优雅停机 + 流量摘除（注册/readiness）保证停机不中断在途请求。

优雅停机是"停新单 + 排空 + 关闭"。流量摘除（注册/readiness）先停止新流量。配合实现无中断停机。