重写 PHP 应用之前，先要一份升级方案

批准替换 PHP 应用的方案之前，先要求一份升级计划。如果没人调查过现有应用能否安全运行在受支持版本上，那么比较选项时就遗漏了一条重要路径。

这个问题正当其时。Clever Cloud 在 9 月 1 日公告中表示，2026 年 10 月 1 日之后发布的镜像将默认采用 PHP 8.5。未指定具体版本或使用通用版本 8 的 PHP 和 FrankenPHP 应用会使用 8.5，已经固定具体版本的应用不受此次默认值变化影响。

这是一家托管商的变化，并不是所有 PHP 应用的统一截止日期。但它提醒依赖 PHP 的企业：谁知道正在运行哪个版本、由谁提供支持，以及版本变化时会发生什么？

先弄清您付费解决的是什么问题

托管默认值变化、运行时失去支持，以及应用不再适合业务，是不同的问题，需要不同回应。将它们混在一起，会让方案难以判断。

PHP 项目的支持时间表显示，PHP 8.2 的上游安全支持于 2026 年 12 月 31 日结束。PHP 8.4 同日结束主动支持，但关键安全修复延续至 2028 年 12 月 31 日。这是很不同的状态。操作系统厂商或托管商也可能有自己的维护安排，单看版本号无法说明全部情况。

例如 Ubuntu 的 9 月 10 日 PHP 安全通知为受影响且受支持的 Ubuntu 版本提供包更新，涵盖其 PHP 8.1、8.3 和 8.5 软件包。正确评估部署，需要核对适用厂商的软件包及支持信息。

这些都不是在讨论重设计时忽略安全维护的理由。需要补丁的应用，在作出更大决定期间仍然需要补丁。

要求看到实际失败的地方

我会从独立测试环境，以及业务不能失去的关键流程清单开始：客户能下单吗？员工能修正订单吗？正确金额能进入会计系统吗？管理员修改权限后，下次登录还正常吗？

随后在目标 PHP 版本上运行这些流程，并检查依赖库和扩展。PHP 的 8.4 至 8.5 迁移指南明确要求切换生产前测试不兼容变化。Clever Cloud 也建议检查扩展是否可用，并在评审或测试环境验证应用。

有用的产出是已观察到的故障、修复所需工作，以及尚未验证的事项。某个无人维护的库可能需要替换，某份报告可能依赖已变化的行为，也可能应用需要的工作远少于重建。只有调查才能知道。

我还会要求把部署和恢复纳入估算。如果升级改变已存储数据，回退可能不只是恢复旧代码。这必须在决定上线日期前写进计划。

那些特殊业务规则仍需要被保留下来

设想一家分销商使用旧订购系统。多数客户结账付款，少数客户有约定账期，还有一个特定导出持续向外部仓库提供订单。这是示例，不是客户故事。

替代系统可以拥有更漂亮的界面，却仍然处理不好这些例外。新团队必须发现哪些规则重要、决定保留哪些，并证明替代方案行为正确。现有应用可能是某些决定唯一完整的记录。

理解这些规则是替换成本的一部分。把它计入估算，并用它验证新实现。升级同样需要检查，因为改变运行时可能暴露现有代码中的假设。

重写也可以有充分理由

有时评估会更有力地支持替换：应用可能依赖无人能够支持的组件，其结构可能难以实现必要权限模型，或业务已发生足够大变化，修复旧流程反而保留了错误方向。

这些理由值得讨论。持续维护成本、能处理系统的人员是否易于找到，以及反复失败的风险，也同样值得考虑。应把重写与可信的维护计划比较，说明各自能让业务做什么，又有哪些问题无法解决。

还可能存在值得先做的小范围替换：迁移一个棘手集成或流程，检查结果，再决定下一步。这也有成本，尤其是两套系统并存时。应先估算，而不是自动推荐。

把下一步决定缩小

收到升级通知时，要求一份有具体交付物的评估：支持状态、检查过的流程、发现的故障、带成本的升级选项，以及有理由的建议。未解决的未知项应清楚列出。

Rosecraft 提供这类技术评估，以及集成与现代化工作，目标是提供足够证据，帮助您选择值得付费的工作。

我喜欢开发新应用。但喜欢开发，并不足以成为要求一家企业替换现有系统的理由。先说明升级涉及什么，再论证为什么需要做更多。