不推倒重写，如何把传统 PHP 系统改造成可交付产品

重写并不总是风险最低的选择

传统 PHP 系统往往已经承载大量真实业务：页面多、入口分散、数据库历史复杂，很多规则只存在于代码和运营习惯里。直接重写看起来干净，却可能把已经稳定的业务行为、边缘场景和数据兼容问题一起丢掉。

更稳妥的策略，是先识别必须保持不变的客户流程，再围绕安全、数据、实时通信、性能和部署建立统一边界。

第一步：把安全边界集中起来

遗留系统的风险通常不是一个醒目的漏洞，而是许多不一致的小入口：某个接口忘记鉴权、某个资源接口相信前端传来的用户 ID、某个 WebSocket 没有绑定真实会话。治理时应先建立统一登录、会话、角色和同源校验，再逐个把历史入口接入。

• 所有后台接口在服务端校验身份和数据归属。

• 上传文件做真实解码、尺寸限制、统一重编码和路径隔离。

• 动态输出统一做上下文编码，数据库查询收紧参数边界。

• 登录错误避免账号枚举，并增加频率限制和审计。

第二步：让 WebSocket 身份与会话一致

HTTP 页面已经登录，不代表 WebSocket 自动可信。客服端和客户侧连接都需要绑定服务器认可的会话，连接建立、心跳、断线和重连也要维护唯一身份，避免重复连接和僵尸在线状态。

修复实时链路时不能只看到 101 握手成功。还要验证双端文本传递、来源校验、会话切换、断线清理和重复登录情况下的行为。

第三步：让查询模式和索引匹配

聊天记录、会话列表、在线状态和系统日志如果没有分页与组合索引，数据增长后一定会拖慢后台。先从真实慢查询和页面访问模式出发，再决定游标、分页和索引，而不是给每个字段机械加索引。

同时清理废弃表、重复接口、孤立资源和测试数据，让数据库结构与当前业务重新对齐。

第四步：用真实点击完成回归闭环

PHP 语法检查只能证明文件能被解析，无法证明权限、JavaScript、模板和 WebSocket 仍能协作。完整闭环应当是静态审计、动态复现、最小修复、浏览器真实点击、数据清理和空环境部署。

• 逐页检查后台业务入口和关键按钮。

• 验证客户侧页面、分享模板及浏览器错误。

• 导出数据库并在空库中完成恢复。

• 从空目录执行安装器，再检查 HTTPS、PHP-FPM、数据库和 WebSocket。

可交付的标准是可以重复验证

遗留系统治理的目标不是把代码改得像新项目，而是把依赖个人经验的运行方式变成可复测、可恢复、可部署的工程流程。只要边界清晰、验证完整，保留成熟业务并渐进改造往往比一次性重写更可靠。