SpringBoot 老项目就像一座住了十几年的老宅子：墙皮开裂、电线老化、水管生锈，但一家老小还住在里面。你明明知道每动一面墙都可能引发塌方，却又不得不忍受每天漏水跳闸的日常。我经手的一个库存管理后台系统，就是这样的“危房”。代码堆了六七年，启动要三分钟，改一个字段牵扯十几个服务，线上出问题要先翻一个多小时日志才能定位到那段烂泥一样的业务逻辑。重构它不是“技术情怀”，而是一笔被逼到墙角的生存账。
先别急着推倒重来，这恰恰是最危险的念头
很多人一提到重构就热血沸腾，恨不得用最新版本的 Spring Boot 3、微服务、K8s 一股脑把旧世界炸平。重构最大的敌人不是老代码，而是“大干快上”的幻想。那个库存系统背后连着 ERP、财务、仓储设备接口，还有三套并行多年的权限校验逻辑。如果真按“重写”来搞，业务不等人，半年后老板看到的只会是一个跑不起来的空壳加一个没法回退的死局。理性做法是把重构当作“带病换零件”，而不是“心脏移植”。先给系统做一次全面体检：哪些模块耦合最重，哪些接口调用频率最高，哪些代码连原作者见了都摇头，然后把烂账按风险级别列成一张“技术债地图”。这张地图就是未来行动的指南针，而不是靠感觉挑软柿子捏。
体检不能只看代码，还要看“活业务”。老系统里往往藏着大量已经失效的功能，比如五年前的双十一秒杀模块，早就没人用了，但逻辑还趴在主流程里。砍掉死业务，比优化活代码更能降低系统混乱度。我曾在那个后台里发现一套“手工调价记录”功能，它被一个废弃的审批流反复触发，占了数据库表容量的三分之一，还在每次启动时参与初始化。把这个功能连同它的定时任务、消息监听一起摘掉后，系统启动时间直接缩短了四十秒。这件事让我明白，重构的真正战场不是代码，而是系统里那些“看起来还在用”的僵尸功能。
用绞杀者策略代替一夜换血
老项目重构的稳妥路径是“绞杀者模式”——让新代码像藤蔓一样包裹旧系统，一点点吸取养分，最后让枯木自然倒下。具体到 Spring Boot 项目，我先在原有工程里开辟出一个独立的modern包路径，所有新接口都走新的请求入口、新的校验逻辑、新的异常处理，而旧接口保持原样。新旧代码之间只通过防腐层通信，绝不允许新代码直接调用旧的 Service 实现。这样做的好处是：每一行新代码都能独立测试、独立上线，出了问题的影响范围被死死锁在包边界内。
防腐层是绞杀者策略的灵魂。我在旧系统里封装了一个LegacyGateway组件，把对旧 Service、旧 DAO、旧缓存的访问全部收敛到这层门面里。新模块想读库存数据，只调用LegacyGateway.queryStock()，至于内部走的是 JdbcTemplate、MyBatis 还是 FeignClient，新模块完全不感知。重构的技术价值不在于你用了多新的语法，而在于你为“变化”留下了多少余地。有了这层门面，后续迁移数据源、替换缓存中间件，都变成修一条路而不是炸一座城。
从最痛的点开刀：接口梳理与契约冻结
很多时候，老项目不敢拆，是因为没人说得清“哪个接口给谁用”。那个库存后台曾被外部供应链系统直接调用上百个 HTTP 接口，参数五花八门，很多还带标准库没有的野路子字段。重构时第一步不是改代码，而是把所有接口的调用方、频率、参数格式拉出来做一次“契约盘点”。没有契约的接口重构，就是在一堆乱麻中剪线头，剪错一根就是事故。我用一周时间写了个简单的过滤器，把所有 HTTP 请求的 URL、报文、来源 IP 记到日志表里，再配合网关的访问审计，最终把接口分成了核心稳定型、内部协作型和废弃可下线型三类。针对核心接口，制定并冻结一套显式契约，任何字段的增减都要经过评审，绝不允许隐式变更。
契约冻结之后，重构就变成“实现层面”的活儿。我把旧接口的响应体统一为标准的Result<T>结构，但为了兼容老调用方，留给它一个自定义序列化注册器，让旧格式继续输出旧字段，新格式输出新字段。兼容不是纵容烂代码，而是为重构赢得足够长的安全过渡期。这个过渡期内，外部系统不需要跟着改，我们内部却可以偷偷把底层从Mysql + Redis + Dubbo迁到PostgreSQL + Valkey + Spring Cloud。
分层治理：先治数据，再治逻辑，最后治代码
很多重构文章上来就谈代码设计原则，但真实项目里最难啃的往往不是 Java 代码，而是数据库和领域模型。那个库存系统里有一张名为stock_record的超级大表，五千多万行，各种字段被复用得面目全非：有个remark字段既存过备注，又存过供应商编码，还存过仓位 ID。如果数据模型是一锅粥，再漂亮的代码层也只是一根精致吸管插在粥里。我先把那些被复用字段拆成独立的关系表，通过一次性脚本迁移数据，然后在新代码中引入强类型 DTO 和枚举，彻底断了“万能字段”的根。
数据层稳定后，领域逻辑的重构才有意义。我用一个周末把原来七百行的OrderServiceImpl按行为拆成了OrderStateMachine、StockReservationHandler、PriceCalculator三个小类，每个类不超过一百二十行。衡量重构成功与否，不是看代码变得多“优雅”，而是看修改一个需求时你能少读多少行无关代码。改了之后，新加一种订单状态只需动状态机配置，而不必在一坨 else if 里捞针。
测试是你的防弹衣，不是你的累赘
老项目没有测试是常态。但重构的时候没有测试，就像蒙着眼睛走钢丝。我不会天真地让大家开始补单元测试，因为旧代码的依赖如蛛网，测试根本 mock 不起来。我的做法是优先构建“特征测试”：把老接口的随机请求和响应录制下来，用Spring MockMvc+WireMock重放，只要重构后响应与录制版本一致，就算过。特征测试就是老项目的回溯测试，它不验证逻辑对不对，只验证行为变没变。这套测试刚开始只有十几个 case，却已经成了每一次重构提交的守门员。有一次我调整了日志切面，结果特征测试抓到一个异常响应的code字段从400变成了405，如果没有它，这个变化会在上线后被外部系统瞬间放大成事故。
测试跑通之后，我才有底气做“增量重构”。每次提交只解决一张技术债地图上的一个点：比如把SimpleDateFormat全部换成DateTimeFormatter，或者把ThreadLocal的TraceId传递改成TransmittableThreadLocal。每一步都是小步子、可回滚。宁可每天提交十次小重构，也不要憋一个月放一颗原子弹。
监控和灰度：把重构当作生产发布来管理
老项目重构最怕的不是改错，而是改错了没人知道。所以我在重构阶段就开始搭建比以往更细的监控：不仅看 JVM 和接口 RT，还要看关键业务量的“数字指纹”——比如每天十点库存扣减的笔数、超卖异常的次数、平均订单金额的分布。监控不是为了看板好看，而是为了识别“意外”与“自然波动”之间的细微差别。我把这些指标做成一个重构健康度面板，每次发布新版代码后，先观察两小时大促级别的流量模拟，再逐渐切真实流量。
灰度发布也是用“绞杀”的思路。我新建了一个独立的网关路由，把 5% 的请求头中包含特定标记的用户打入新模块，其余仍然走老逻辑。老系统不是不能用，但它应该像一个退役的老将军，逐步被替换而不是突然被辞退。两周后，新模块稳定，再把灰度比例调到 50%，最后全量。这过程中一旦发现任何异常，我只需要改一个配置项，就能把流量瞬间切回老系统。
团队协作里的“重构礼仪”
技巧讲完，还有更关键的人的因素。不少重构项目不是死在技术上，而是死在团队配合上：后端埋头改接口，前端毫不知情；运维照着旧脚本重启，结果新配置没生效；产品经理还在按旧功能写需求文档，导致开发对不上版。重构必须是跨职能的“合唱”，而不是程序员的独奏。我推动成立了“重构周同步”机制，每周四下午，后端、前端、测试、运维、产品五个人站在一起过一遍本周的变更清单和下周的影响面。不用写复杂文档，只需要一张 Excel 表，列清模块、改动范围、需要配合的人和回滚方式。
这个机制最初被嫌太麻烦，但坚持一个月后，最明显的成果是线上事故减少了三分之一，而且很多隐患在同步会上就被提前掐灭。同事开始主动问：“这个字段我要改，你们那边会有影响吗？”——这才是重构真正落地的基础。重构能否成功，取决于团队愿不愿意与其和平共处，而不是把它当一次性的冲顶运动。
重构后的日子，才是真正开始
如今那个库存系统还在运行，代码量从原来的 18 万行降到了 13 万行，启动时间从 180 秒降到了 35 秒，部署频率从每月 2 次变为每周 10 次。它依然不是一个完美的系统，还会时不时冒出一些历史遗留的synchronized块或new Date()乱象，但我们已经有了技术债地图、特征测试和灰度通道。真正的重构成果不是一座崭新的宫殿，而是一套让老房子持续翻修而不崩塌的施工体系。每次看到新同事能在一个下午读懂一个模块并愉快地提交代码，我就知道：当初那些战战兢兢的深夜，值了。
如果你也面对一个历史包袱沉重的 Spring Boot 老项目，我的建议只有一句：别急着证明自己有多厉害，先让旧系统活到下个季度。用最小的步幅、最稳的节奏、最无聊的方法，把重构变成一种日常习惯，而不是一次壮烈的革命。当技术债被一张张地还清，你会发现，所谓“老项目”，不过是还没开始认真翻修的家。
)