Spring Boot 4 + Spring Framework 7 核心

• Spring Boot 4 与 Spring Framework 7 的基线要求
• AOT 优化在框架层的落地
• HTTP Service Client 接口稳定的意义

Spring Boot 4 与 Spring Framework 7 将 JDK 17 作为最低版本要求，并针对 JDK 21+ 的虚拟线程、结构化并发等特性做了优化适配。关键演进之一是 AOT（Ahead-Of-Time）优化：框架层在构建期对 Bean 定义、配置元数据、代理等进行裁剪与预编译，为 GraalVM Native Image 提供更好支持，同时降低启动时间与内存占用。另一个重点是 HTTP Service Client 接口稳定：Spring Framework 7 将声明式 HTTP 客户端（HTTP Interface）由实验性转正为正式特性，使其成为 WebClient 之外的稳定替代方案。整体上，Spring Boot 4 面向"云原生、虚拟线程、原生镜像"的现代运行时，帮助应用在保持 Spring 生态的同时获得更好的启动与资源效率。

这一演进的核心是"适配现代 Java 与云原生"：抬高 JDK 基线以利用新特性，AOT 优化服务原生镜像与冷启动，HTTP Interface 稳定提供了更简洁的远程调用方式。

• Spring Modulith 的模块化理念与边界检测
• 事件外化（application events externalization）机制
• 跨模块事务的边界与工程实践

Spring Modulith 帮助在单体应用内建立清晰的模块边界，通过 Modulithite 工具对模块依赖关系进行静态分析，检测模块间不合理的直接依赖（如包级循环、未声明依赖），将架构约束"可测试、可验证"。它通过模块内 @ApplicationModule 与 @ApplicationModuleListener 组织模块事件，并支持"事件外化"——将模块间通信通过 Spring ApplicationEvents 解耦，进一步可发布到 Kafka 等消息中间件，为未来拆分微服务做准备。跨模块事务方面，Modulith 建议避免跨模块的长事务，将事务边界限定在单个模块内部，模块间通过事件异步协作，以保持一致性并降低耦合。工程实践上，先从边界检测入手，识别并消除违规依赖，再逐步引入事件外化，最后按需拆分独立服务。

Modulith 的价值在于"先治理单体、再低风险拆分"：通过强制边界与事件解耦，让单体保持可维护性，同时为微服务演进铺路。事件外化是解耦的关键，跨模块事务应尽量避免。

• ChatClient 的流式与同步调用 API
• Tool Calling 与模型工具调用
• Advisors 链式拦截、Vector Store 抽象与 Prompt 模板

Spring AI 2.0 提供面向 AI 应用的 Spring 化抽象。ChatClient 提供流式/同步的对话调用 API，并有 Builder 风格配置。Tool Calling 允许将 Java 方法注册为模型可调用的工具，模型在生成时按需调用工具并回填结果。Advisors 提供链式拦截机制，可对每次对话调用做前置/后置处理（如记忆注入、日志、安全过滤），类似 AOP 拦截器。Vector Store 抽象统一了不同向量数据库（PGVector、Milvus、Redis 等）的存取与相似度检索接口，便于 RAG 实现。Prompt 模板引擎支持基于模板（如 {{question}}）的提示词构建，支持变量替换与多角色消息。这些抽象让 AI 集成的代码可移植、可测试，并深度融入 Spring 生命周期。

Spring AI 的核心价值是"用 Spring 的方式抽象 AI 集成"：ChatClient 统一调用、Tool Calling 打通 Java 能力、Advisors 做横切、Vector Store 抽象检索、模板引擎管理提示词，从而降低多模型切换与工程化成本。

• Java 基线升级带来的编译与运行影响
• Modulith 引入对现有应用结构的影响
• 迁移评估与风险控制

Spring Boot 4 将 JDK 17 作为最低基线，这意味着现有应用需要先保证在 JDK 17+ 上可编译运行，涉及已废弃 API、依赖版本、字节码版本等兼容性检查。Modulith 是"可选"能力，不会强制改造现有应用结构，但若应用引入 Modulith 模块化，就需要识别模块边界、重构包结构、消除违规依赖，这是结构性的影响。迁移影响面可分为：编译/运行层面（JDK 基线、依赖兼容、Spring 配置）、结构层面（引入 Modulith 时的模块边界梳理）、以及行为层面（AOT 下部分反射/动态代理行为的差异）。建议先做基线与依赖兼容性验证，再按需引入模块化，避免一次性大改。

迁移影响面需区分"强制"与"可选"：JDK 基线是强制门槛，Modulith 是可选项。合理的迁移是"先达标、再优化"，避免将可选能力当作强制改造。

• AOT 对 Bean 定义与实例化流程的影响
• 构造注入优先的原因
• 提前实例化与反射替代

在 AOT（Ahead-Of-Time）模式下，Spring 在构建期就解析 Bean 定义、生成 Bean 注册代码与实例化逻辑，取代运行时反射与条件判断。这带来两个变化：一是构造注入优先——AOT 更适合构造器注入，因为 Bean 的依赖关系在构建期可静态推导，便于生成确定的实例化代码，而字段注入依赖反射，难以提前静态化；二是提前实例化——AOT 将可确定的 Bean 提前在构建期实例化/注册，运行时直接装配，减少启动时的反射与扫描开销。相应地，@Configuration 的代理、@Autowired 的字段注入、@Value 解析等的运行时行为在 AOT 下可能有差异，需按 AOT 约束调整。对大多数应用，构造注入本就是推荐方式，AOT 进一步强化了这一最佳实践。

AOT 的本质是"把运行期反射工作前移到构建期"，因此依赖静态可推导的构造注入、提前实例化更契合。理解 AOT 对反射与动态代理的约束，是迁移与使用的前提。

• HTTP Interface 声明式客户端的能力
• 与 WebClient 的定位差异
• 选型依据

HTTP Service Clients（HTTP Interface）是 Spring 基于声明式接口的 HTTP 客户端：通过 @HttpExchange 定义接口方法，Spring 自动生成实现，方法签名即请求语义，简洁、类型安全、易测试。WebClient 是响应式、全功能、可编程的 HTTP 客户端，支持流式、背压、非阻塞，需要更多样板代码。取舍上：若追求声明式、类型安全、与业务模型对齐的远程调用，HTTP Interface 更合适，且底层可用 WebClient 或 RestClient 实现；若需要细粒度控制、流式响应、背压与非阻塞场景，WebClient 更合适。实践中常将两者结合，HTTP Interface 用于结构化服务调用，WebClient 用于复杂场景。

两者不是替代关系而是互补：HTTP Interface 提供高层的声明式抽象，WebClient 提供底层的响应式能力。按"对控制的需求"与"对简洁度的偏好"取舍。

• JSpecify 标准注解的定位
• Spring 7 与 JSpecify 的集成
• 空安全注解的工程边界与限制

JSpecify 是多方协作的 Java 空安全注解标准，提供 @Nullable、@NonNull 等注解，旨在统一不同框架的空安全注解。Spring 7 将空安全注解对齐到 JSpecify，使 Spring 的 API 空语义可被 IDE 与静态分析工具识别，从而在编译期或开发期发现空指针风险。工程边界在于：注解本质是"开发期/静态分析"的元数据，不改变运行时行为；非空注解的保证依赖代码契约与工具校验，运行时仍可能遇到绕过校验的 null；且需配合支持 JSpecify 的工具链（如 IntelliJ、Error Prone）才能发挥效果。因此空安全注解是"提升质量"的辅助手段，而非运行时防御。

空安全注解的价值是"把空语义显式化、把空指针风险提前到编译期"，但其边界是"不提供运行时强制"。理解这一点才能正确评估其收益与局限。

• 自动配置与 Starter 命名变化
• 与 3.x 的兼容性
• 升级清单的制定方法

Spring Boot 4 对自动配置与 Starter 命名做了收敛与调整，例如将部分自动配置类重命名、统一命名规范，并引入新的模块化组织。与 3.x 的兼容性总体遵循"渐进式"原则：核心配置（application.yml）、大部分自动配置坐标保持兼容，但依赖类、包名、配置属性可能调整，部分废弃 API 被移除。升级清单准备应包括：1) 对照 Spring Boot 4 迁移指南，逐项核对配置属性与自动配置类；2) 检查第三方 Starter 的版本兼容性；3) 用 spring-boot-maven-plugin 的依赖校验与 spring-boot-configuration-metadata 校验配置；4) 全量功能回归测试，重点验证自动配置生效、Bean 装配与 Web 行为。分步升级（先 3.x 最新 → 4）可降低风险。

升级清单的关键是"系统化核对"：迁移指南 + 配置校验 + 依赖兼容 + 回归测试。理解命名与自动配置的变化，避免"只改版本号"式升级。

• Modulith 的模块边界与依赖原则
• 跨模块事务的问题与规避
• 事件驱动的一致性设计

Modulith 要求模块有明确的边界与依赖方向，模块间通过公开的 API 与事件通信，避免隐式包级依赖。跨模块事务边界设计上，Modulith 不推荐跨模块的长事务，因为事务跨越模块会引入分布式事务复杂度与强耦合。替代方案是：将事务边界限制在单个模块内，跨模块的一致性通过"事件外化 + 最终一致"实现——模块 A 在本地事务内发布领域事件，模块 B 通过事件监听消费并执行自己的本地事务，配合可靠投递（如 Outbox 模式）保证最终一致。对需要强一致的关键场景，则明确界定事务归属，避免一个事务横跨多个模块。设计原则是"模块内事务、模块间事件"。

跨模块事务边界的设计核心是"以事件解耦替代事务耦合"：模块内保强一致，模块间用事件与最终一致。这样既降低耦合，又保持数据一致性，是 Modulith 的推荐模式。

• AOT 引擎在 Spring Boot 4 中的角色
• GraalVM Native Image 的构建期优化
• 反射/代理/资源的自动注册

Spring Boot 4 将 AOT（Ahead-Of-Time）引擎作为构建期优化的核心环节，在编译期分析应用上下文、生成 Bean 注册与实例化代码，并自动收集 GraalVM Native Image 所需的反射、动态代理、资源、序列化等"reachability"元数据。这些优化使 Spring Boot 应用能编译为原生镜像，得到毫秒级启动、更低内存与更小镜像体积，同时 AOT 也服务于普通 JVM 的启动加速。构建期优化包括：裁剪 Bean 定义、消除运行时配置解析、生成静态初始化代码、自动注册反射与代理 hint。对开发者而言，原生镜像下需注意动态特性（反射、加载外部类、Class.forName）的受限边界，可使用 Spring 的 RuntimeHints API 显式声明。

AOT 是 Spring Boot 4 支持原生镜像的引擎：把运行时反射探测前移到构建期，生成 reachability 元数据。理解"动态特性受限"这一边界，是原生镜像落地的关键。

• 结构化/JSON 日志的默认行为
• 日志桥接的选择
• 对可观测性的影响

Spring Boot 4 将结构化日志（Structured Logging）作为默认能力，支持以 JSON 格式输出日志，便于日志采集、索引与统一分析（如与 ELK、Loki 集成）。在日志桥接上，Spring Boot 4 统一了日志后端选择，明确默认使用 Logback 之上的日志桥接，减少多日志框架之间的冲突（如 SLF4J 与 java.util.logging 的桥接）。结构化日志的好处是每个日志事件为结构化对象，字段可检索、可过滤，配合 MDC 与 traceId 可支持链路追踪。默认值方面，Spring Boot 4 倾向于默认开启 JSON 结构化输出，并可通过配置调整格式与字段。工程上需注意日志量、性能与安全（是否输出敏感字段）。

结构化日志解决的是"日志可机读、可检索"的问题，默认化 JSON 是云原生可观测性的趋势。日志桥接默认统一则减少了多框架冲突的配置负担。

• 对虚拟线程的支持方式与边界
• GraalVM Native 的支持约束
• HTTP/3 的支持现状

Spring Framework 7 对虚拟线程提供支持：可通过 Tomcat/Jetty 等容器配置虚拟线程（spring.threads.virtual.enabled），Servlet 请求处理与部分异步处理可运行在虚拟线程上，同时支持 StructuredTaskScope 等并发新特性。边界在于：虚拟线程并非所有阻塞场景都自动最优，加锁/同步块仍可能钉住，且部分依赖"每线程一个 Pool"的旧库需适配。GraalVM Native 方面，Spring Framework 7 深度支持 Native Image，但动态特性（反射、动态代理、Class.forName）受限，需通过 AOT 与 RuntimeHints 声明。HTTP/3 支持取决于底层容器与网络库，Spring Framework 7 提供一定抽象，但完整 HTTP/3 仍依赖底层实现，属于"渐进支持"而非开箱即用的默认能力。

支持边界体现在"提供能力但不保证所有场景最优"：虚拟线程需注意钉住，Native 需约束动态特性，HTTP/3 依赖底层实现。理解边界才能正确选型与落地。

• GraalVM Native Image 的默认支持程度
• Spring AOT Cache 的作用
• 对构建与运行的影响

Spring Boot 4 将 GraalVM Native Image 作为一等公民支持，提供专用 Maven/Gradle 插件生成原生镜像，并提供 AOT 引擎在构建期生成 Bean 注册代码与反射/代理元数据。Spring AOT Cache 是 AOT 过程中的缓存机制：将 AOT 生成的元数据与构建中间产物缓存，使增量构建时无需重复执行 AOT 分析，加快构建速度。它的意义在于：构建一次原生镜像往往耗时较长，AOT Cache 能复用未变化的元数据，显著缩短重复构建时间。对开发者而言，原生镜像默认支持意味着"编译即优化"，但需自备足够的构建内存与时间，并处理动态特性受限的边界。

Native Image 默认支持 + AOT Cache 的组合，既让原生镜像成为常规路径，又通过缓存缓解构建耗时的痛点。理解构建链路与缓存价值是落地关键。

• JDK 最低版本要求
• Jakarta EE 11 的采用与影响
• 对现有应用与依赖的影响

Spring Framework 7 将 JDK 17 作为最低版本要求，并针对 JDK 21+ 的虚拟线程、结构化并发等提供优化。同时 Spring Framework 7 采用 Jakarta EE 11 作为基础规范，Servlet 6.1、JPA 3.2、Validation 3.1 等 Jakarta 命名空间进一步演进。Jakarta EE 11 的影响在于：相关 API 的包名沿用 jakarta.* 命名空间（自 EE 9 起已从 javax.* 变更），依赖的 Servlet/JPA/Validation 实现需升级到对应的 EE 11 版本；同时 API 的增强（如 Servlet 6.1 对虚拟线程的支持）为 Spring 利用新特性提供了基础。对现有应用，需将依赖的 Web 容器、持久化实现、校验实现升级到兼容 Jakarta EE 11 的版本。

Spring Framework 7 的基线是"JDK 17 + Jakarta EE 11"，它们共同决定了依赖的升级范围。理解 Jakarta EE 命名空间与版本，是评估迁移影响的前提。

• HttpExchange 注解与接口定义
• 自动生成实现与底层执行器
• 声明式远程调用的设计优势

HTTP Interface 客户端允许通过普通 Java 接口声明远程调用：在接口方法上使用 @HttpExchange（或其派生注解 @GetExchange、@PostExchange 等）定义 HTTP 方法、路径、请求头、请求体与返回类型，Spring 在运行时自动生成接口实现，将 @HttpExchange 方法映射为实际的 HTTP 请求。设计上，接口签名即契约，类型安全、可读性好、易于测试（可注入 Mock）。底层可由 WebClient 或 RestClient 执行请求，支持同步、阻塞与响应式等不同风格。它的优势在于"声明式 + 类型安全 + 可移植"，适合作为服务间调用的统一抽象，也便于与 Spring 依赖注入无缝集成。

HTTP Interface 的设计哲学是"接口即契约"：把远程调用从"样板代码"变为"声明式描述"，Spring 负责生成实现。理解其底层执行器与自动生成机制是正确使用的前提。

• Micrometer 的指标抽象
• OTel 的集成与统一
• 对可观测性体系的影响

Spring Boot 4 强化了基于 Micrometer 的观测性能力：Micrometer 提供统一的指标 API，可输出到 Prometheus、OTLP 等多种后端。在 OTel 集成方面，Spring Boot 4 将 OpenTelemetry 作为一等公民，支持通过 Micrometer 将指标映射到 OTel Metric 协议，并通过 OTel 实现统一的 trace（链路追踪）、metric（指标）与 log（日志）关联。演进方向是"统一 OTel 语义"：metrics 与 traces 通过 OTel 的语义约定（Semantic Conventions）对齐，使 Java 应用的可观测性数据可直接接入 OTel Collector 与后端。对开发者，Spring Boot 4 提供自动配置的 OTel 集成，并支持无侵入的自动 instrumentation。

观测性演进的核心是"统一到 OTel 语义"：Micrometer 负责指标抽象，OTel 负责统一协议与端到端关联，形成"指标 + 追踪 + 日志"的一致体系，减少多后端对接的复杂度。

• 主要废弃 API 与移除项
• 迁移路径与替代方案
• 对现有代码的影响

Spring Framework 7 作为主版本，会废弃并移除部分旧 API，常见包括：过时的 javax.* 相关、早期 @Repository/@Service 等注解的某些边界用法、以及部分已废弃的 WebMvcConfigurerAdapter 等旧类。迁移路径一般是官方 migration guide 中提供替代 API，例如 WebClient/RestClient 替代 RestTemplate 的旧用法、HTTP Interface 替代部分手写客户端、Micrometer Observation 替代旧的自定义观测。对现有代码，需通过编译告警（-Xlint:deprecation）识别废弃使用，再按替代方案逐个迁移，并做全量回归。建议在升级前先清理废弃 API 使用，避免迁移叠加。

主版本升级通常伴随废弃 API 的清理。迁移路径的关键是"先识别废弃、再按官方替代方案替换、最后回归验证"，避免依赖已移除的 API。

• @ServiceConnection 的自动连接
• Testcontainers 在测试中的价值
• 测试改进的方向

Spring Boot 4 强化了 Testcontainers 集成，核心是 @ServiceConnection 注解：在测试中声明一个 Testcontainers 容器（如 PostgreSQL、Redis、Kafka），@ServiceConnection 会自动将该容器的连接信息注入到 Spring 上下文对应的连接池/Client（如 DataSource、RedisConnectionFactory），无需手动配置 JDBC URL 等。这大幅简化了"用真实依赖做集成测试"的搭建成本。测试改进还包括：更强的 1:1 测试支持、测试切片（Test Slices）的简化、以及针对 AOT/原生镜像下的测试适配。工程价值在于用真实容器提升测试可信度，减少"测试通过、生产不通过"的偏差。

@ServiceConnection 解决的问题是"容器连接与 Spring 上下文的接线"——自动注入连接信息，让集成测试更贴近生产。理解其自动装配机制是高效使用 Testcontainers 的关键。