Spring Boot 4的启动时间变快了，但Spring团队反复澄清：性能优化只是副产品，真正的目标是把代码拆干净。
2024年SpringOne大会上，团队首次披露模块化重构的完整逻辑——不是为了跑分好看，是为了让依赖关系从"意大利面条"变成"乐高积木"。
这个决策背后藏着一道经典的产品选择题：用户喊的是"快"，但工程师看到的是"乱"。Spring Boot用了十年时间把自动配置（Auto-configuration）做成行业标配，却也积累了大量隐性债务。每次启动时，类路径扫描要遍历数百个配置类，其中大部分对当前应用毫无意义。
模块化不是减法，是重新画边界
Spring Boot 4的模块化改造分三步走：首先把自动配置类按功能域拆分，其次引入模块描述符（Module Descriptors）声明依赖关系，最后让构建工具只打包实际用到的模块。
结果很直观。Uber JAR（可执行胖包）体积缩小，启动时的类加载量减少，但团队工程师Juergen Hoeller在Q&A环节强调：「我们不是为了优化启动速度而做这件事。」
真正的收益在维护侧。以往一个团队想禁用某块自动配置，得在代码里打补丁或者排除依赖。现在可以直接声明"我不需要数据访问模块"，构建系统会自动裁剪传递依赖。
这种设计哲学和Linux内核的模块化异曲同工——不是为了省电，是为了让裁剪变得可预测。Spring团队花了两年时间梳理内部依赖图，把原本隐式的"自动配置全都要"变成显式的"按需组装"。
Spring Framework 7：把重试和限流收编进内核
同步发布的Spring Framework 7做了一件事：把分散在各处的可靠性模式收拢到核心框架。
RetryTemplate、@Retryable、@ConcurrencyLimit这些功能过去需要额外引入Spring Retry或第三方库，现在直接内置。Spring工程师Rossen Stoyanchev解释：「这不是功能扩张，是承认这些模式已经成为基础设施工具箱的标配。」
迁移路径设计得很克制。现有使用Spring Retry的项目可以继续运行，但新代码可以直接用框架原生注解。团队预计，未来两个大版本后会逐步淡化外部依赖。
这个决策的时机耐人寻味。云原生场景下，瞬时故障和背压处理几乎是每个服务的必修课，但开发者要在"引入新依赖"和"自己造轮子"之间反复纠结。Spring选择替用户做掉这道选择题——代价是核心框架的代码量增加约12%，但团队认为这笔交易划算。
HTTP API版本策略：Spring不再替你做主
Spring Framework 7的另一个变化是显式化。过去版本对API版本控制（API Versioning）的态度是"提供工具但不表态"，现在则在文档中列出了四种策略的完整决策矩阵。
路径版本（/v1/users）、请求头（Accept-Version）、查询参数（?version=1）、媒体类型参数（application/vnd.api.v1+json）——每种方案都附带了适用场景和权衡说明。Stoyanchev坦言：「没有银弹。网关层架构、团队规模、客户端分布都会改变最优解。」
这种"把选择权还给用户"的做法，和Spring Boot 4的模块化形成有趣对照。一边是帮用户砍掉不需要的，一边是拒绝替用户决定需要的。核心逻辑一致：框架应该暴露复杂度，而不是假装它不存在。
AI编程工具：Spring团队在"投喂"自己的上下文
采访中最具前瞻性的部分是关于AI编码助手的讨论。多位Spring团队成员将其描述为"transformative"（变革性），但具体行动比口号更务实。
团队正在研究如何把Spring特有的设计模式、最佳实践、版本差异转化为AI可消费的上下文。这包括结构化文档、代码示例的语义标注、以及常见错误的模式库。目标不是做一个"Spring专用AI"，而是让通用助手在回答Spring相关问题时少 hallucinate（产生幻觉）。
Hoeller提到一个细节：「我们注意到AI在生成Spring配置时，经常混用不同版本的语法。」这恰恰是模块化带来的新挑战——当Spring Boot 4的自动配置拆分后，AI需要更精确地理解模块边界才能给出正确建议。
从3到4：升级成本被刻意压低
对于存量用户最关心的迁移问题，Spring团队给出了相对乐观的判断。典型应用的升级工作量"可控"，支撑这一判断的是三项具体措施：
Jackson 2兼容模块允许渐进式迁移，不必一次性重写所有序列化逻辑；官方迁移指南按应用场景分类，而非简单罗列变更清单；社区支持渠道（Stack Overflow标签、GitHub Discussions）被纳入正式支持体系。
一个值得注意的信号是：Spring Boot 4的最低Java版本要求仍是Java 17，而非外界猜测的Java 21。团队解释这是基于用户调研数据——生产环境中LTS版本的采纳速度比开发者社区感知得更慢。
这种"向后兼容优先"的保守主义，和模块化重构的激进形成张力。但换个角度看，两者指向同一目标：降低用户的决策成本。要么帮你拆清楚（模块化），要么帮你省掉升级决策（兼容旧版本）。
采访最后，Stoyanchev被问到"Spring的下一个十年会是什么样"。他的回答很克制：「我们不再预测技术趋势，只回应用户真正卡住的地方。」
这句话或许解释了为什么Spring能在Java生态中持续占据C位——不是因为它总能押对方向，而是它把"替用户省时间"这件事做了二十年。当AI开始重写代码时，这种产品直觉会变成新的护城河，还是会被直接绕过？团队没有给出答案，但他们在做的上下文工程暗示了赌注的方向。
热门跟贴