Spring Boot 4 模块化架构扫盲笔记

下班之后没人亲亲，敲段代码哄自己开心。写个demo修完bug，誓让女神喊你哥哥。

一句话概括

Spring Boot 4 把原来”一锅炖”的自动配置，拆成了独立的”小火锅”——按需取用，互不干扰。

为什么要模块化？

以前的痛点

假设你写一个简单的 REST 接口：

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "Hello";
    }
}

在 Spring Boot 3.x 里，引入一个 spring-boot-starter-web，它会：

• 加载 Spring MVC
• 加载内嵌 Tomcat
• 加载 Jackson（JSON处理）
• 加载 Spring Validation
• 加载… 还有一堆你可能用不到的东西

问题：启动慢、内存大、依赖臃肿。

4.x 怎么改的？

核心思路：拆分

把原来的 spring-boot-autoconfigure 大包，拆成多个独立模块：

实际体验

以前：

<!-- 引入 web 包，所有功能全进来 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

现在（按需选择）：

<!-- 精确引入，只用哪个引哪个 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-webmvc</artifactId>
</dependency>

模块化的具体升级点

1. 依赖更精细

2. 启动更快

• 只加载业务需要的模块
• 减少类路径扫描
• 优化启动时间

3. 内存占用降低

• 按需加载，告别”一启动就吃 500MB”的尴尬
• 微服务场景下优势明显

4. 可维护性提升

• 模块边界清晰
• IDE 提示更精准
• 贡献者更容易入手特定模块

对开发者有什么影响？

✅ 好消息

• 轻量级应用更轻了：一个简单接口服务可能只需 100MB 内存
• 启动时间大幅缩短：开发体验更好
• 依赖冲突更少：只引需要的，减少版本冲突概率

⚠️ 需要注意

• 依赖写法变了：以前用 starter，现在可能需要查文档用具体模块名
• 迁移时注意：老项目的依赖可能需要调整
• 不是完全重写：自动配置的底层逻辑还在，只是拆分更细

升级建议

渐进式

Spring Boot 2.x → 3.x → 4.x

不要跳级！

先检查依赖

确认你的依赖是否已有 4.x 兼容版本，特别是：

• 第三方 starters
• 中间件客户端
• 监控/链路追踪组件

总结

模块化本质：把”瑞士军刀”拆成”专用工具”——用哪个拿哪个。

PS：模块化是进步还是倒退？

spring-boot-starter 最开始的设计是引用一个就能干所有事，现在需要自己判断引用哪个，是否是技术倒退？

我的看法：不是倒退，是技术成熟后的必然分叉。

两阶段设计哲学不同

本质：Spring Boot 从”帮你省事”转向”帮你省钱省资源”。

为什么是进步而非倒退？

1. 复杂度的转移

• 以前：框架帮你做决策 → 你省心，但付出资源代价
• 现在：框架给你工具 → 你做决策，换取精确控制

这是从”保姆模式”升级到”工具箱模式”——不是退步，是信任用户。

2. 云原生的现实压力

• 容器按内存/核心计费
• Serverless 冷启动要快
• 微服务数量多，每个实例省 100MB 就是真金白银

“全家桶”在云时代是奢侈品。

3. 技术栈分化加剧

现在一个项目可能用：

• Web（传统 Servlet）
• WebFlux（响应式）
• GraalVM Native Image
• Kotlin 协程

一个 starter 包打天下已经不现实，技术选型本就需要判断。

那到底是不是增加负担？

看你怎么用：

负担的本质：是你需要知道”我到底在干什么”——这个认知成本是必须支付的。

类比一下

从”套餐”到”自助餐”——不是倒退，是给你选择权。

我的观点

• 框架设计：没有倒退，是响应时代需求（云原生、资源敏感）
• 开发者体验：确实增加了认知成本，但也给了更多控制权
• 技术选型：负担不在”要判断依赖”，而在于”要理解自己项目的真实需求”