PHP 项目最可能发生的“剧本”
如果非要选一个最经典、最普遍、最可能发生的剧本,我认为是：
🎭 “遗留系统永续维护”剧本
也就是俗称的 “屎山代码” 剧本。
典型剧情走向
- 起源（3-5年前）：某位已经离职的“大神”用当时流行的框架（可能是 ThinkPHP 3.2、CI、Yii、甚至原生 PHP）快速搭了个能跑的系统。
- 野蛮生长：业务催得急，需求天天变，代码开始“打补丁”——
if套if，复制粘贴,全局函数满天飞。 - 版本锁死：PHP 5.6 或 7.1 一直不敢升级，因为“升了就崩”，Composer 依赖锁定在几年前的版本,漏洞补丁打不上。
- 人员更替：原作者离职，新来的接盘侠看一眼代码就想跑路,但又跑不掉。
- 现状：线上在跑，不敢重构，改动一处崩三处；每次发版靠 FTP 上传或者
git pull到服务器；没有测试，没有文档，var_dump就是调试器。 - 终局：要么“带病运行”到业务下线,要么某天爆发重大事故后被迫重写。
为什么这个剧本概率最高？
| 因素 | 说明 |
|---|---|
| PHP 的历史包袱 | 大量中小项目起于 2010 年代，PHP 入门门槛低，写烂代码的成本也低 |
| 外包/甲方文化 | 交付即结束，没人管长期维护，代码质量无所谓 |
| 人才流动 | PHP 开发者转 Go/Java 的多，留下维护的人少 |
| 业务优先 | “能跑就行”是压倒一切的原则 |
| 升级成本高 | PHP 5→7→8 的破坏性变更，让老项目动弹不得 |
其他高频剧本（作为备选）
- “框架迁移地狱”：TP3 → TP5 → Laravel，迁一半发现迁不动,两套并存。
- “安全事件惊魂”：某天发现
eval($_POST['x'])后门，或者 SQL 注入被拖库。 - “性能瓶颈突袭”：流量一涨，N+1 查询和没加索引的表直接把 MySQL 打挂。
- “Composer 依赖地狱”：
composer update之后整个项目起不来,只能回滚。
一句话总结：PHP 项目最可能的剧本不是“优雅地演进”，而是“在屎山上继续盖楼，直到某天塌了再说”。
你是遇到了哪种剧本？可以具体聊聊,我帮你分析对策。
