接手别人做的系统二开为什么风险高？什么时候应该重做？

结论：二开还是重做必须由技术尽调决定，不能用系统年龄或“改动超过 60%”一刀切。

滚水科技首先确认旧系统能否合法取得源码和依赖、在干净环境构建部署、保护现有数据并用测试覆盖关键业务。能保留的稳定资产就保留；无法验证的核心逐步替换。完整重做是风险最高的选项之一，因为旧系统中未被记录的规则也可能一起丢失。

在比较平台能力、限制与迁移成本时，还可以对照 低代码、零代码平台能不能替代定制开发？什么时候该用哪种？ 和 旧系统本地部署太卡且安全压力大，重做上云需要考虑什么？；这些内容补充了需要放在同一项决策中考虑的上下文。

二开的风险来自未知依赖，不只是代码难看

新团队不知道哪些行为是业务规则、历史补丁还是偶然缺陷；数据库字段可能被报表和外部接口隐式使用；第三方 SDK、构建仓库、证书或云账号可能不在客户手里；没有回归测试时，一处修改的影响无法量化。责任争议也要用基线解决：接手前记录现有缺陷、版本和环境，后续才能判断变化来源。

路线	适用证据	主要风险	第一项验证
继续维护 + 局部二开	构建可重复、核心稳定、改动边界清楚	技术债仍限制未来变化	在隔离分支完成一项代表性变更与回归
包裹旧核心、外围新建	核心规则难替换但有稳定接口	新旧数据与故障边界复杂	建立契约、观测和回滚路径
按模块渐进替换	模块可切分，业务不能长时间停机	双系统并存和迁移对账	选择低耦合且可独立验收的第一模块
完整重做	资产不可用/无权使用，核心模型完全不符且替换可承受	遗漏隐性规则、迁移和切换失败	用真实业务样本证明新模型覆盖旧规则

尽调必须产出可复现证据

第一步盘点代码仓库、分支、构建链、部署、数据库、文件、接口、域名证书、云账号和第三方合同，确认所有权与访问权。第二步在新的受控环境从源码构建并部署，记录依赖和密钥缺口。第三步扫描依赖、漏洞和许可证，形成 SBOM；SPDX 规范提供描述软件组件、许可证和安全引用的标准方式，但清单仍需人工核实实际分发义务。

第四步用生产日志、用户访谈和样例数据找出关键业务任务，为现状建立特征测试：先固定当前可接受行为，再修改。第五步评估数据质量、迁移键、外部消费者、性能和安全。NIST 的安全软件开发框架 SSDF要求保护软件、减少漏洞并响应残留问题，可用于建立接手后的安全实践，但不能单独给出重做结论。

尽调周期由规模、访问完整性和风险决定，不统一承诺一至两周。输出应包括可构建证明、资产/依赖图、现有缺陷基线、核心流程测试、数据画像、风险分级、三个路线的工作分解和首个验证计划。若连生产版本对应哪个源码提交都无法确认，报价必须包含恢复基线的工作，而不是假装已知。

重做也要把旧系统当作待迁移业务证据

决定重做后，仍不能只依据新 PRD。抽取真实订单、权限、报表和异常案例，逐项说明迁移、归档或停止；旧系统保留只读与审计能力到法定/业务期限。采用按模块或用户群切换，设置对账、停写、回退和数据冻结点。新旧双写很容易出现顺序和一致性问题，只有在明确冲突解决和可观测性后使用。

路线比较应看未来一段合理周期的总成本与风险：旧系统每次变更工时、故障、安全暴露、人员可获得性，与新建、迁移、双运行和培训成本。代码行或功能百分比没有统一分母，不能用于“超过某数就重做”。某个很小的结算核心可能决定全局，而大量静态页面可以低成本替换。

滚水科技在正式承接前会书面列出原有缺陷、未知项和责任边界；二开提交必须有回归证据、数据库迁移与回滚；渐进替换则为每个模块定义流量切换和退出条件。客户拥有代码、数据和账号，避免新团队再次成为下一个无法接手的供应商。