凌晨两点，钉钉群炸了。
不是那种有人发了个表情的小震动，是连环call轰炸，夹杂着截图和完了完了的表情包。生产环境PHP进程疯狂报错，call_user_func_array报deprecated，opcache.get_headers那套直接白屏。用户刷不出订单，支付页面转圈转了三十秒最后报错。客服电话被打爆，排队等了快十分钟才有客服接起来——接起来也不知道该说什么。值班开发一边手动重启服务一边骂娘，骂完还得写故障报告，写到凌晨四点，写完也没吃饭，直接趴键盘上睡着了。
这就是没做版本评估的代价。真实的，血淋淋的，不是网上那些假设场景。
我跟你说这事，是因为类似的事情我见过不止一次了。有一次是个做在线教育的客户，周五晚上突然收到大量用户反馈视频看不了。一查，日志里全是Deprecated: Function each() is deprecated这种错误。PHP 7.2升级到7.4的时候，each()函数被标记废弃，他们代码里到处都是这东西。五十多个调用点分布在十五个不同的文件里，那晚上整个团队干到凌晨三点才把热修复发上去。
很多人对PHP版本升级有误解，觉得不就是改个配置文件的事。兄弟，你可能没经历过一个2009年的遗产系统在PHP 7.4上跑了五年，突然要迁移到8.x的那种酸爽。Composer依赖里躺着十几个最后更新于2018年的包，有的连个像样的测试用例都没有。这种项目，动一刀都可能引发蝴蝶效应。你永远不知道哪个犄角旮旯里的代码会突然跳出来咬你一口。
那怎么办？凉拌？躺平？说等下一代再做？
说个具体的。上个月我接手一个电商项目，客户说他们统计了下，核心业务代码大概30万行，历史三年没人敢动。技术栈停在PHP 7.2，扩展版本一律不敢更新。我问他为什么不升级，他说怕出事。怕出事，就不做事？这逻辑我没法认同。你怕出事，但你不做事，问题就不会消失，它只是在你最不想看到它的时候出现，而且往往是以最惨烈的方式出现。
评估要趁早。拿到PHP 8.4的发布路线图之后，第一件事不是去翻新特性，不是去看那个match表达式多优雅、那个命名参数多方便，而是把代码里所有trigger_error、E_USER_DEPRECATED调出来看一遍。这些玩意儿在新版本里可能会直接抛异常，不是warning，是中断执行。php.ini里的error_reporting配置该改就得改，别到时候手忙脚乱。我见过有人升级完才发现自己的错误处理逻辑完全没考虑新版本的异常抛出机制，整个业务逻辑直接崩溃。
第三方扩展的兼容性列表必须过一遍。尤其是Redis、Memcached、Swoole这些运行时依赖，一旦版本断档，系统说塌就塌。我见过有人升级完PHP才发现Swoole 4.x根本跑不起来，4.4需要另外编译，那个夜晚他一个人对着服务器抽烟到天亮。事后他跟我说，那晚他抽了半包烟，脖子都僵了，第二天脖子直接落枕，一周才好。你说惨不惨？还有一次是个金融系统，升级PHP的时候没检查MySQL扩展的兼容性，结果连接池直接漏了，每秒丢十几个连接，数据库直接被打挂。那一晚的损失，够他评估三个月了。
测试环境要干净。不是指代码干净，是指环境配置要和生产一致。我建议直接拿生产快照克隆一份，跑完整的回归测试。有人说这太奢侈，但你想过没有，生产事故的代价是多少？一次大的生产事故，人力成本、客诉成本、赔偿成本、还有最重要的品牌信誉损失，加起来够你搭十套测试环境。
还有个土办法——找边缘流量入口先切。比如管理后台、内部工具，用户少，出问题也能快速回滚。别一上来就把主交易链路扔上去赌命。我之前建议一个团队先拿他们的CRM系统开刀，那系统就几十个人用，结果一跑起来发现四十多个兼容性问题。如果当初直接上交易系统，那才叫灾难。
代码层面，有个笨办法但有效：把所有@符号压下去的error都搜出来，逐个分析。有些老代码写的时候就知道有问题，但人家加了@就不管了，这种债迟早要还。我见过一个函数，@符号压了八年，最后系统迁移的时候才发现那函数根本没返回值，全靠错误抑制活着，一去掉@整个业务流程都变了。你说这是谁的锅？
我不鼓吹盲目升级，也不认同能拖就拖。真正的决策逻辑是：评估风险边界、制定回滚预案、确定灰度节奏。说白了，就是把不确定性变成可控的已知项。
现在去看一眼你项目里的composer.json，PHP版本写的什么？再看一下php -v。这是第一步，也是最简单的一步。很多人卡在不知道从哪开始，但其实开始很简单，难的是承认现状然后真的动手。你的系统现在是什么版本？有哪些依赖已经落后了？有哪些历史债务在等着你？你打算什么时候开始面对？