老App是重做还是打补丁？成本差距都卡在哪些事上

老App是重做还是打补丁，核心判断依据不是代码写得烂不烂，而是未来一年的业务逻辑会不会有大变化。按2026年移动端项目交付习惯，先做业务增量与基础架构匹配度评估，再决定是重构还是修补，能省掉大量返工时间。两者没有通吃所有场景的方案，只看适不适合当下的业务阶段。

先分清“旧”和“乱”：两个问题别混为一谈

重做还是修补，首要分辨的是App到底“旧”还是“乱”。“旧”偏指技术栈老化，比如目标SDK版本过低、第三方库停更、系统兼容窗口收窄；“乱”偏指代码和业务结构纠缠，新需求接不进去、排查问题靠猜。很多团队把“旧”当成重做理由，实际上老而不乱，依然能稳妥迭代；“乱”才是重做的主要理由，因为继续往上加需求会使缺陷数量指数级上涨。

在项目交付现场，甲方常卡在“要不要跟新框架”的纠结里。我们见过一款资讯类App，技术栈沿用多年，新功能每次都要绕开旧逻辑，最后不得不花两个月把核心链路拆出来重写；另一款App技术较老但模块边界清楚，只升级目标SDK、做兼容适配三个月就恢复上架状态。所以先花一周做代码体检，把“旧”和“乱”分开记录，是做好决策的第一步。

四个判断标准：先别急着下结论

从移动端定制开发交付经验看，重做与修补的分水岭，不在代码新旧，而在业务增量与现有架构的匹配度。下列四个问题，倾向“是”的多为修补信号，倾向“否”的则要谨慎评估重做。

• 业务主链路是否稳：登录、支付、下单等核心流程，近半年改动次数是否很少。改动频繁说明业务还在快速试错，此时重做容易反复返工。
• 新需求还进不进得去：新增一个页签或角色，能否在一到两个开发日内完成。需要一周以上且每次都要动地基，说明结构已经拖累迭代。
• 线上质量是否还受控：崩溃率是否连续高于行业习惯基线（比如千分之五到百分之一），且三个月内没有明显下降。失控时修补只是止血，根因往往在架构层。
• 接手的同事能否讲清结构：换一个人来维护，能否在三周内梳理出核心链路和关键依赖。讲不清的代码库，新增需求的风险会成倍放大。

四个问题里若有三项以上指向“否”，建议先按下面五步验证法做一轮评估，再定重做还是修补，而不是凭感觉拍板。

五步验证法：重做前把结论做扎实

与其反复争论该不该重做，不如用一个可执行的核对流程把结论跑出来。这套方法适合产品、技术、运营一起参与，能有效减少“做完才发现选错路”的情况。

1. 体检基线：收集线上崩溃率、启动耗时、核心链路错误率，连续观察一周，设定未来三个月的整改目标。
2. 梳理链路：画出核心业务的主链路，标出每个节点的依赖（登录、支付、消息、数据统计），找出哪些模块改动最频繁。
3. 标准打分：对照上述四个判断标准逐项打分，分别给出“重做”和“修补”的预期成本、周期和风险区间。
4. 最小验证：在现有版本上挑选一个高频页面做一次“伪重做”，按新标准重写并上线，看团队实际投入和反馈速度。
5. 小范围试运行：新结构先在一个非核心模块灰度运行，对照崩溃率和用户反馈，再决定是否全面推开。

每一步都要有明确交付物：体检报告、链路图、成本对照表、上线记录和灰度数据。把这些留在项目文档里，后续做验收也有依据。注意第2步最容易漏掉老数据迁移与第三方账号合并，第4步能直观反映现有工程改良的真实难度。

成本与周期：重做和修补的差异在哪

按2026年移动端项目交付习惯，两者投入差异较为明显。从成本结构看，重做是“推倒重建”，修补是“加固楼体”。重做需要需求梳理、UI重绘、服务端改造、数据迁移、回归测试全套流程；修补则主要围绕线上问题与局部重构展开。

• 重做：研发周期6到10个月（经验区间，不含需求反复）；费用按团队量级单独评估，通常是修补路线的2-3倍。
• 修补：常见迭代6周到3个月，费用约为重做路线的30%-50%；前提是现有架构还能容纳增量需求。
• 风险：重做最大风险在数据迁移与用户习惯变化；修补最大风险在旧问题被继续带进下一阶段。
• 团队：重做建议由“懂业务+懂老系统”的双角色团队主导；修补需要熟悉老代码逻辑的成员守住核心链路。

重做路线的钱花在哪

重做的开支大头通常不在UI，而在数据迁移与老接口兼容。老App的用户表、订单表、消息记录都要换到新结构，历史数据回放和报表口径也很容易对不上。按经验，重做项目里数据迁移与联调往往占整体工期的三成以上，这块不能漏出预算。

修补路线的钱花在哪

修补主要花在“旧代码改造”上。常见项目是升级目标SDK、兼容新系统、修崩溃、替换停更的三方库，再做一次回归。如果老代码没有测试用例，修补也会边改边冒新问题——所以第一条建议是先把高频主链路的自动化回归补上，否则越修越乱。

适用场景与边界

适合重做的情况

• 业务模式本身在变：比如从免费转付费、从单角色变多角色，老结构绕不过去，改造成本接近重做。
• 核心链路经常出事故：崩溃、卡顿、数据错乱的根因需要跨模块排查，且反复修反复犯，说明架构瓶颈已到临界。
• 老代码缺少可测试边界：改动一个参数会影响多个页面，自动化测试完全铺不开，任何变更都像走钢丝。

不适合重做的情况

• 只想换界面换配色：这类需求走主题包或局部改版更划算，重做会带来无谓的用户迁移成本。
• 技术栈体系没有坏：目标SDK半年内未要求强制升级，开发环境还能正常发布，这就没有重做的紧迫性。
• 团队人手不足：重做需要分工完整的小组，否则很容易做到一半又退回修补，反而浪费前期投入。

常见问题

老App重做周期要多久？

按经验区间，常规业务老App重构在6到10个月，数据量大会先做迁移预演，周期还可能延长。

修补老App的成本大概多少？

常见修补周期是6周到3个月，费用约为重做的三到五成，具体取决于改动范围。

重做后老用户需要重新登录吗？

如果沿用原账号体系并做好会话迁移，多数情况可以保持登录状态；第三方登录需要提前确认。账号合并相关工作量需预先评估，这是容易被忽略的一环。

老数据迁移容易出哪些问题？

常见问题集中在历史订单、积分余额、消息记录和报表口径对不上，迁移前建议先做数据抽样比对和回滚预案。

行动建议：先安排一个开发周做代码体检，按四个判断标准和五步验证法把结论写出来，再决定重做还是修补。若业务主线稳定、只是技术栈旧，修补是低成本选项；若业务模式即将重构、老代码又缺测试边界，重做更适合长期投入。无论选哪条路，数据迁移和兼容性任务都要提前排进计划。以上为通用经验区间，具体方案建议结合你的App量级与团队情况单独评估。按犀跃公司移动端交付习惯，重做前会先做一周代码体检并出具报告，再进入报价与排期，能显著减少中途改口。