# 老系统二开还是推倒重构：一份决策参考 原文：https://www.99idc.cn/blog/legacy-system-refactor-vs-extend.html 作者：广深互联技术团队 发布时间：2026-11-09T08:09:00+00:00 内容更新时间：2026-11-03T09:23:23+00:00 ## 摘要 老系统到底是继续二次开发还是推倒重来？本文列出支持二开的信号、支持重构的信号，以及中间路线绞杀者模式，并附一份可以直接对照的决策清单。 ## 正文 ## 引言 几乎每家做了几年信息化的企业，都会在某个阶段遇到同一个纠结：手上这套老系统，业务上还在跑，但要加个新功能比登天还难；修个Bug要小心翼翼，生怕碰坏别处。到底是在原来的代码上继续二开，还是咬牙推倒重来、重做一套？ 这个问题没有标准答案，但有相对清晰的判断信号。我们这些年接过不少"二开老系统"的活，也接过不少"从老系统迁到新系统"的活，见过两种选择各自的后悔现场。本文把支持二开的信号、支持重构的信号、以及中间路线"绞杀者模式"分别讲一讲，最后给一份可以直接对照的决策清单。 ## 一、先承认一件事：推倒重来是最贵的选项 在展开讨论之前，有一个观念要先摆正：推倒重构是代价极高的动作，不应该是默认选项。 为什么这么说？重构意味着： - 业务要在一段时间里跑在两套系统之间，数据迁移、历史数据清洗、人员重新培训，都是实打实的成本； - 老系统里那些"没人记得为什么这么写、但一直在跑"的隐性逻辑，很容易在重构中被丢掉，上线后冒出一堆"以前不是这样的"； - 新系统上线后的磨合期，通常比预期长得多。 行业里有一句被反复引用的话："重写系统是创业公司最常见的死法之一。"这话放在企业自研系统上也成立。所以默认选项应该是二开，除非有足够强的信号说明二开走不下去了。 ## 二、支持二开的信号 如果下面这些情况占了多数，二开通常是更划算的选择： 业务流程没大变。 老系统上线时设计的那套流程，今天用起来基本顺手，只是要补几个功能、改几个报表、加几个角色权限。这种情况下，系统的业务模型是对的，动代码只是"加肌肉"，不是"换骨架"。 代码结构还能读。 虽然老，但目录清晰、命名大致合理、有基本的注释和文档。新人接手一两周能看懂主流程，改一个功能不会牵动全身。 团队还接得住。 原来的开发人员还在，或者有一支熟悉这套技术栈的团队。技术栈本身没有过时到招不到人的程度。 性能和稳定性还在可接受范围。 数据量在当前架构下还能撑，没有天天崩、天天慢，偶尔加机器、加索引能扛住。 只补几个功能。 未来一两年的需求清单是"加几个模块、改几个页面、对接一两个外部系统"，不是"整个业务模式变了"。 满足这些条件，老老实实二开，比折腾重构省钱省心。 ## 三、支持推倒重构的信号 反过来，如果下面这些信号反复出现，就要认真考虑重构了： 技术栈过时到招不到人。 比如系统还跑在十几年前的框架上，相关维护人员与生态支持已明显减少，想找个能维护的开发都难。这时候每加一个人成本都很高，代码没人敢动。 Bug修不完，修一个冒两个。 系统已经进入"碰哪哪坏"的状态，回归测试越做越长，每次上线都像赌博。这说明代码已经腐化到了一定程度，二开的边际成本越来越高。 业务已经大改。 老系统是按十年前的业务模式设计的，今天业务流程、组织架构、商业模式都变了，硬在旧骨架上改，等于在自行车上改汽车。 每次上线都像赌博。 没有自动化测试、没有CI/CD，发布靠运维手动操作，版本管理混乱。这种情况下，继续在上面加东西，风险会指数级上升。 安全和合规上已经欠债。 比如跑在不再维护的语言版本上、存在已知的高危漏洞、数据结构不满足新的合规要求。这种情况下，重构不只是技术问题，也是风险问题。 ## 四、中间路线：绞杀者模式 二开和重构之间，其实还有一条被越来越多企业采用的中间路线，叫"绞杀者模式"（Strangler Fig Pattern）。 它的核心思路是：不一次性推翻老系统，而是在老系统外面新建一套新系统，按业务模块一块一块地替换，老系统像藤蔓被新树逐步绞杀一样，慢慢退役。 具体做法通常是： - 新老系统并行运行，通过网关或接口做流量分发； - 先挑一个边界清晰、风险低的模块在新系统里重做，把这部分流量切过来； - 跑稳之后，再切下一个模块； - 每切一块，老系统的职责就少一块，直到最后完全下线。 这种方式的好处是：可以减小单次切换范围，但数据一致性、写入归属、验证与回退必须逐步设计，不能保证每一步天然无中断、可回退。代价是周期长，可能持续一两年，但相比一次性大爆炸式重构，总体风险和业务冲击都小得多。 如果你的情况介于"还能二开"和"必须重构"之间，绞杀者模式往往是更务实的选择。 ## 五、一份决策清单 最后给一份可以直接拿去开会用的清单。逐项记录证据，再权衡业务连续性、关键风险和总成本；安全等关键约束不能简单按票数抵消： 维度：倾向二开：倾向重构 业务流程：基本稳定，只补功能：已发生根本变化 代码可读性：新人两三周能上手：没人敢动、动了就崩 技术栈：仍在主流维护周期内：已停止维护、招不到人 团队：有熟悉这套系统的人：原团队已散，新人接不住 性能：加机器/索引能扛：架构瓶颈已到顶 上线风险：常规发布可控：每次上线都像赌博 安全合规：没有明显欠债：已有难以修补的漏洞 如果拿不准，可以先做一次代码和架构体检：请外部技术团队或资深开发把系统通读一遍，评估技术债务、关键模块耦合度、数据迁移难度，再做决策。拍脑袋选二开或重构，两边都容易后悔。 ## 六、广深互联怎么做 广深互联这些年接过不少"老系统续命"的项目。我们的做法通常是先做一次现状梳理：把业务流程、代码结构、数据规模、现存痛点列清楚，再判断是走二开、还是按绞杀者模式逐步替换，很少一上来就建议客户推倒重做。 对业务还在跑、只是要补功能的系统，我们倾向于在原架构上做轻量改造；对技术栈确实老旧、每次迭代都胆战心惊的系统，我们会建议按模块逐步迁移，而不是一次性大爆炸。如果你也在这个纠结点上，可以参考广深互联官网 (https://www.99idc.cn/)上关于系统定制和二次开发的服务说明，或者翻一翻广深互联技术博客 (https://www.99idc.cn/blog.php)里关于系统架构与重构的相关文章。 ## 小结 老系统二开还是重构，本质上是一道"现状评估题"，不是一道"技术偏好题"。默认二开，除非有足够强的信号说明二开走不下去；介于两者之间时，优先考虑绞杀者模式，把大风险切成小步走。在做决定之前，花一笔钱做一次认真的现状评估，比拍脑袋上线一个大项目要划算得多。 作者：广深互联技术团队