PIGX 6.0 发布：AI 时代，我们为什么还要古法编程？

Boot 3 的倒计时已经打到了最后一格。

2026 年 6 月 30 日，Spring Boot 3.5 的 OSS 支持正式截止。这是 Boot 3 系列最后一个 minor 版本，过了这个日期，Spring 官方不再为 Boot 3 提供安全补丁和 bug 修复。

不是追新，是 Boot 3 已经快没人管了。

古法编程依旧重要

AI 工具太方便以后，我们很容易默认自己不用再学新特性了，把升级任务丢给 AI，让它改依赖、换包名、修编译，最后人只负责点一下合并。

在真正迁移 Spring Boot 4 之前，我们认真考虑过这个问题：能不能让 AI 帮我们做迁移？

理论上看起来很香。把 pom.xml 甩给 Claude 或者 Codex，让它帮你把 Boot 3 的依赖改成 Boot 4 的，再扫一遍代码改包路径，几分钟搞定。

试了，不行。（笔者在 Opus 4.7 + Codex 5.5 xHigh 测试）

Boot 4 的 GA 版本是 2025 年 11 月发布的，大多数 AI 的训练数据截止在这之前，给你的包路径大概率是 Boot 2、3 的旧地址，看着合理，编译或运行时才爆。幻觉问题也是，Boot 4 对包结构的拆分很细，AI 容易把独立出来的 spring-boot-cache、spring-boot-jdbc 拼错。

最后的做法是先跑 OpenRewrite，自动改掉能改的，剩下靠人盯。

OpenRewrite 是一个代码自动化重构工具，最初由 Netflix 开源，现在由 Moderne 维护。它的核心思路是把代码迁移任务封装成”Recipe”（配方），由工具自动扫描和修改代码，不需要人逐行去改。Spring 官方提供了专门针对 Boot 升级的 Recipe，在 pom.xml 里加几行配置跑一下 Maven 就能执行。

UpgradeSpringBoot_4_0 Recipe 主要帮我们做了这几件事：

• spring-boot-starter-web → spring-boot-starter-webmvc（Boot 4 明确拆分了 MVC 和 WebFlux）
• 移除 Undertow 依赖和相关配置（Boot 4 不再支持 Undertow）
• 新增 spring.jackson.use-jackson2-defaults: true（明确使用 Jackson 2 默认行为）
• management.endpoints.access.default: none（Actuator 默认不暴露端点）
• OAuth2 Authorization Server 包路径更新

自动化能覆盖约三成，七成还是手工。

依赖优化

主版本升级是重头戏。根 pom.xml 的变动：

1
2
3
4
5
6
7
8
9

<!-- Before -->
<spring-boot.version>3.5.11</spring-boot.version>
<spring-cloud.version>2025.0.1</spring-cloud.version>
<spring-cloud-alibaba.version>2025.0.0.0</spring-cloud-alibaba.version>

<!-- After -->
<spring-boot.version>4.0.6</spring-boot.version>
<spring-cloud.version>2025.1.1</spring-cloud.version>
<spring-cloud-alibaba.version>2025.1.0.0</spring-cloud-alibaba.version>

Spring Boot 自身的模块化拆分

Boot 4 对自身的 Starter 做了更明确的拆分，这部分变动比第三方依赖更容易被忽略。几个影响面比较广的：

AOP 这个变更容易踩到：PIGX 里审计模块、Excel 模块、幂等模块都依赖 AOP，Boot 3 时用 spring-boot-starter-aop 可以隐式拿到，Boot 4 要显式声明 spring-boot-starter-aspectj，不加就是运行时切面失效，不报错也不生效。

自动配置类路径同样做了拆分，如果你的代码里有 exclude = {XxxAutoConfiguration.class} 的写法，要同步检查路径是否还对。比较典型的几个变化：

1
2
3
4
5
6
7
8
9

# Boot 3
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

# Boot 4
org.springframework.boot.data.redis.autoconfigure.DataRedisAutoConfiguration
org.springframework.boot.cache.autoconfigure.CacheAutoConfiguration
org.springframework.boot.jdbc.autoconfigure.DataSourceAutoConfiguration

第三方 Starter 的版本对齐

Boot 3 时代的第三方 Starter 大量使用 spring-boot3-starter-* 命名，Boot 4 有对应的独立坐标，替换前要把旧的彻底清干净：

同步升级的第三方依赖：Flowable 7.x → 8.0.0、XXL-Job → 3.4.0、Druid → 1.2.28、Nacos Client → 3.1.2、Seata → 2.5.0。OSS 模块从 AWS SDK v1 迁移到了 v2，顺手把 AmazonS3 换成同步 S3Client，接口更简洁。

有个容易被忽略的坑：javax.servlet-api 和旧版 spring-security-oauth2 要从 BOM 里彻底清掉。不清干净，下游模块会出现传递依赖冲突——编译能过，运行时类加载失败。Boot 4 全面切到 Jakarta EE，javax.* 包已经不在了，留着就是定时炸弹。

Jackson 3，我们没升

Spring Boot 4 默认切到了 Jackson 3，这是本次升级最大的破坏性变更之一。

Jackson 3 相比 Jackson 2 的 API 层面变化不小：ObjectMapper 行为有差异，部分注解改名，JsonMapper 成了推荐用法。

不是不想升。是升了之后，生态跟不上。

PIGX 的用户场景比较特殊：框架对外提供的是 Starter，下游用户可能还挂着大量依赖 Jackson 2 的第三方 Starter，比如各种报表、流程、消息组件。如果我们升到 Jackson 3，这些组件在序列化层面就会和框架产生冲突，用户需要同步替换所有第三方依赖，迁移成本无法控制。

我们的选择：本期不升 Jackson 3，继续用 Jackson 2。Boot 4 提供了向下兼容的配置支持，一个配置项搞定大部分问题：

1
2
3

spring:
  jackson:
    use-jackson2-defaults: true

但这一个配置不够。Jackson 在 PIGX 里有五条独立的路径：MVC 的 HTTP 响应序列化、Feign 的服务间调用、Redis 的缓存序列化、XSS 清洗的反序列化、日志脱敏的序列化。每条路径都要明确接入统一的 Jackson 2 ObjectMapper，否则会出现”同一个对象，不同路径序列化结果不一样”的诡异 bug。

Feign 那条路最麻烦。Boot 4 环境下 OpenFeign 默认用 Jackson 3，服务间调用的 HttpMessageConverter 列表要单独替换：

1
2
3
4
5
6
7

@Bean
public HttpMessageConverterCustomizer pigxFeignJackson2Customizer(ObjectMapper objectMapper) {
    return converters -> {
        converters.removeIf(c -> c instanceof JacksonJsonHttpMessageConverter);
        converters.add(0, new MappingJackson2HttpMessageConverter(objectMapper));
    };
}

Jackson 3 的完整迁移会在后续版本单独处理，本期目标是稳定上线。

Nacos：官方不升，我们自己来

这是整个升级过程里最出乎意料的部分。

PIGX 使用 Nacos 作为注册和配置中心。Boot 4 升级完成后，Nacos Server 本身也需要适配，因为 Nacos 内部有大量的 javax.* 包和 Jackson 相关代码。

我们联系了 Nacos 官方团队，得到的回复是：暂时没有支持 Spring Boot 4 的计划。

没有计划就自己搞。我们 fork 了一个分支 pig-mesh/nacos，主要处理了三类问题：

javax → jakarta 迁移。 Nacos 代码里大量使用了 javax.servlet.*、javax.annotation.* 等包，需要全量迁移到 jakarta.*。这部分工作量不小，但机械性强，可以批量处理。

JSON 升级后认证鉴权报错。 Nacos 内部的 JSON 序列化升级之后，认证 token 的解析出现问题，导致鉴权失败。根因是序列化库版本切换后某些字段的处理方式变了，手动修复兼容逻辑。

Jraft 升级后 raft 选举失败。 这个最难定位。Nacos 集群模式依赖 Jraft 做 raft 共识，升级 Jraft 版本之后，选举过程中出现状态机异常，集群无法选出 Leader。最终通过一路修到发电厂 编译一个新的 Jraft 版本来解决这个问题。

详细日志

后端变更明细

前端变更明细

总结&资源汇总

虽然 AI 正在快速改变软件开发的方式，Vibe Coding 也让写代码变得更加高效，但它并没有改变企业级软件对稳定性、可维护性和工程质量的要求。

我们始终认为，所谓“古法编程”并没有过时。扎实的框架设计、清晰的架构边界、稳定的基础能力，依然是各类项目最核心的价值。

PIGX 始终致力于构建高质量、稳定的企业级开发底座，为 AI 时代的软件开发提供可靠支撑。

• PIGX 6.0 代码下载：https://pig4cloud.com/data/other/form3.html?v=2026
• PIGX 6.0 详细介绍：https://paper.pig4cloud.com
• PIGX 6.0 演示环境：http://home.pig4cloud.com:38081