SpringBoot4升级实录，Jackson3默认切换引发的序列化漂移与多库兼容陷阱

当 Maven 构建显示全绿、本地 clean package 成功时，开发者往往误以为 Spring Boot 4 升级已告一段落。然而，Forge Admin 团队在将系统从 Boot 3.5.x 升级至 4.1.1 的第一周便发现：联调环境频繁出现金额字段解析异常、脱敏逻辑失效、超大 JSON 请求未被拦截、代码生成器生成的 ServiceImpl 编译失败，甚至 Flowable 流程引擎升级后无法回退至 7.x 版本。这些并非偶发故障，而是 Spring Boot 4 在协议默认值、容器能力边界与第三方库主版本强绑定三方面发生结构性变化所致。

Spring Boot 4 的核心变动之一是默认 JSON 序列化器从 Jackson 2 切换为 Jackson 3。这一改动看似平滑，实则埋下严重隐患。Forge Admin 长期依赖 Jackson 2 的 Jackson2ObjectMapperBuilderCustomizer 实现字段级加解密与大整数（如 Long 类型金额）的定制序列化逻辑；而其集成的 MCP（可能是某中间件通信协议）Java SDK 则需使用 Jackson 3 的 JsonMapper。若两者共用全局 ObjectMapper Bean，将导致序列化行为混乱——前端看到的金额值可能被截断或格式错乱，脱敏字段在部分接口生效、部分失效，且因线程竞争难以复现。

为解决该问题，Forge 团队采取分栈隔离策略：业务 HTTP 层显式指定使用 Jackson 2，通过 application.yml 配置项强制锁定：

同时，Flowable 流程变量存储也同步配置 flowable.variable-json-mapper: jackson2，防止历史 JSON 数据因 Jackson 3 的语义变更被错误反序列化。加解密模块继续挂载于 Jackson 2 的构建器上，由 forge-starter-crypto 中的 JacksonCryptoConfiguration 统一管理。MCP 通信层则单独注入带 @Qualifier("mcpServerJsonMapper") 注解的 Jackson 3 JsonMapper，并通过 JacksonMcpJsonMapper 封装层隔离两套栈，避免冲突。

第二类典型问题是 Tomcat 对请求体大小的默认限流机制弱化。Boot 3 中 RequestResponseBodyMethodProcessor 会隐式校验 Content-Length 并触发 HttpRequestHandlerAdapter 的限流逻辑；而 Boot 4 中该路径被简化，若未显式配置 RequestBodyLimitFilter，超大 JSON 请求（如 >10MB）将绕过拦截直接进入业务层，可能导致 OOM 或反序列化耗时剧增。Forge 在升级分支中补入了自定义 Filter，并在 application.yml 中设定了 server.tomcat.max-http-form-post-size 与 spring.mvc.max-request-size 双重约束。

第三类坑点来自 MyBatis-Plus 的包结构重构。3.5.7 版本中 mybatis-plus-spring 模块尚未独立，而 3.5.17 已将其拆出为独立 artifact。若项目仍沿用旧版依赖声明（如仅引入 mybatis-plus-boot-starter），Spring Boot 4 的自动配置扫描可能因 @MapperScan 路径不匹配导致 ServiceImpl 类无法实例化，表现为“Service implementation not found or bean cannot be instantiated”。Forge 的解决方案是显式声明 mybatis-plus-spring 依赖，并校准 mapper-locations 与 type-aliases-package 配置，确保类扫描路径覆盖新包结构。

第四类涉及 Sa-Token 与 Redis Session 类型变更。Sa-Token 1.45 在 Boot 4 下要求使用 sa-token-spring-boot4-starter，其默认 Session 存储类型从 RedisSession 改为 RedissonSession。若旧版应用残留 RedisSession 类型数据，重启后将因反序列化失败导致登录态丢失，表现为异步任务中偶发“未授权访问”。Forge 通过在启动时注入 SaTokenDao 实现兼容性桥接，并在测试环境中执行一次性数据迁移脚本，将旧 Session 格式转换为新结构。

第五类则是 Flowable 8 的不可逆 Schema 变更。Flowable 8 引入了新的流程定义存储格式与权限模型，其数据库 Schema 与 7.x 不兼容，且无官方回滚工具。Forge 在兼容分支中采用双库策略：联调环境使用独立测试库，升级前备份 7.x 数据快照；正式上线前通过 flowable-migration-tool 执行前向迁移，并验证所有历史流程实例的可读性与可恢复性。值得注意的是，Flowable 8 移除了 applicationTaskExecutor 自动配置，需手动注册 ThreadPoolTaskExecutor 以支持异步任务调度，否则会导致定时任务堆积或线程泄漏。

上述五类问题均非编译期可捕获的语法错误，而是运行时行为漂移，凸显 Spring Boot 4 升级的本质挑战：它不仅是版本号递增，更是对默认契约、依赖边界与运行时语义的重新定义。Forge Admin 最终在独立兼容分支中完成 T0–T6 全量兼容矩阵测试，确认与 Spring AI 2.0.1、Redisson 4.8.0 等组件协同稳定后，才将底座升级合入主线。其经验表明，升级前必须明确三件事：一是识别哪些功能依赖旧版默认行为；二是评估第三方库主版本是否同步演进；三是设计可验证的回归测试路径，而非仅依赖构建成功。

目前，Spring Boot 4.1.1 已成为新项目推荐基线，但存量系统迁移仍需谨慎。社区反馈显示，除 Forge 外，多个中大型企业级后台系统在升级过程中均遇到类似 Jackson 序列化漂移或 Flowable 兼容问题。官方虽提供 spring-boot-migrator 工具辅助分析，但关键仍在于理解底层变更逻辑——毕竟，真正的“兼容”不是让代码通过编译，而是让行为保持一致。