PHP升级后网站白屏或报错，90%的情况能在错误日志里直接看到弃用（E_DEPRECATED）和致命（Fatal error）提示——关键不是“有没有日志”，而是你是否在日志里主动筛选出版本兼容性线索。

怎么确认error_log里真有兼容性报错？

PHP版本升级（比如从7.4升到8.1）后，很多函数、语法、扩展行为会变，但不会立刻崩，而是先发警告。这些警告默认可能被过滤掉，导致你只看到空白页，却看不到真实原因。

error_reporting 必须包含 E_DEPRECATED，否则像 mysql_connect()、create_function()、each() 这类已被标记“下个版本移除”的调用，日志里压根不记

别只信 php.ini 里的设置：FPM 模式下，www.conf 中的 php_admin_value[error_reporting] 会强制覆盖它，用 php -i | grep error_reporting 看实际生效值

临时加一行代码验证：error_log('test deprecation', 0); trigger_error('test E_DEPRECATED', E_DEPRECATED);，然后查日志末尾有没有两行——没第二行，说明 E_DEPRECATED 被屏蔽了

grep 命令快速筛出兼容性关键词

日志文件动辄几百MB，手动翻等于浪费时间。直接用命令定位真正该关心的几类报错：

grep "Deprecated:" /var/log/php/error.log —— 所有弃用提示，例如 Deprecated: Function mysql_connect() is deprecated

grep "Fatal error" /var/log/php/error.log | grep -i "call to undefined function\|class.*not found\|attribute" —— PHP 8+ 新增限制，比如调用被移除的函数、未声明的 attribute、类名大小写敏感问题

grep -E "(Array and string offset access|Dynamic property)" /var/log/php/error.log —— PHP 8.1+ 严格化数组/字符串偏移、动态属性访问，常见于旧框架（如早期 Laravel、CodeIgniter）

为什么有些兼容性错误日志里根本找不到？

不是没发生，是它们根本没走 PHP 的 error_log 流程：

Parse error 和 Fatal error 发生在脚本编译/加载阶段，如果发生在 require 或 include 的文件里，而该文件又没被任何运行时逻辑触发，它可能只出现在 Web 服务器日志（如 /var/log/apache2/error.log）中，而不是 PHP 自己的 error_log

某些框架（如 Symfony、Laravel）把错误吞掉再抛自定义异常，此时 error_log 是空的，得看框架自己的日志（如 storage/logs/laravel.log）

PHP-FPM 子进程崩溃（segfault）不会进 error_log，要看系统日志：journalctl -u php*-fpm -n 50 或 dmesg | tail -20

日志里看到 “Undefined array key” 却找不到对应代码？

这是 PHP 8.1+ 默认开启的严格模式报错，但它的触发点往往藏在“看起来没问题”的地方：

不是你写的 $arr['key'] 报错，而是某个第三方库内部用了 $$var 动态变量，或 array_merge($a, $b) 其中一个为 null，PHP 8.1 开始会把这种隐式转换也报成 Undefined array key

检查报错行附近的 foreach、list()、extract()，这些是高频雷区

临时加一句 ini_set('error_reporting', E_ALL & ~E_NOTICE & ~E_DEPRECATED);，如果错误消失，基本可断定是 PHP 8.1+ 新增的严格检查，而非逻辑缺陷

真正难的不是找到报错，而是区分哪些是必须改的兼容性断裂（比如函数被删），哪些只是升级带来的严格提示（比如数组键检查）。后者可以先压制，但前者拖得越久，后续升级成本越高——尤其当你的日志里反复出现同一个 Deprecated 提示，说明那块代码已经站在淘汰边缘了。

Tags: PHP错误日志 PHP版本兼容性报错

分享到：