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