PHP升级后必须立即检查日志，因兼容性问题、扩展失败、函数弃用等均隐藏其中；需分Web（phpinfo()）和CLI（php -v/-i）验证版本一致性，并重点排查error_log、Web服务器错误日志及PHP-FPM日志中的Deprecated、Warning、SIGSEGV等关键词。
PHP 版本过低必须升级，但直接升级后不检查日志，等于没升级——很多兼容性问题、扩展加载失败、函数弃用警告（如 mysql_connect）全藏在日志里，线上服务可能悄无声息地降级甚至崩溃。
怎么看当前 PHP 版本和实际运行版本是否一致
很多人改了 php.ini 或重装了包，却仍跑着旧版本，因为 Web 服务器（如 Nginx/Apache）或 CLI 调用的不是新二进制。务必分环境验证：
- Web 环境：新建
info.php，内容为<?php phpinfo(); ?>，通过浏览器访问，重点看Loaded Configuration File和PHP Version - CLI 环境：执行
php -v和php -i | grep "Loaded Configuration File"，确认路径与 Web 环境一致 - 如果版本不一致，检查 Web 服务器配置中
php-fpm的 socket 或端口是否指向新版本的php-fpm进程（比如/run/php/php8.2-fpm.sock而非php7.4-fpm.sock）
升级后必查的三类日志位置和关键词
PHP 升级后的问题不会立刻报错，但会沉淀在日志中。重点盯住：
-
error_log（由php.ini中error_log配置指定）：搜索Deprecated、Warning、Notice，尤其注意Function xyz is deprecated或Uncaught Error: Call to undefined function - Web 服务器错误日志（如 Nginx 的
/var/log/nginx/error.log）：查找upstream prematurely closed CGI、recv() failed，常因 PHP-FPM 启动失败或子进程崩溃导致 - PHP-FPM 自身日志（
php-fpm.conf中error_log配置项）：检查WARNING: [pool www] child 12345 exited on signal 11 (SIGSEGV)类致命错误，多由扩展不兼容引起
常见升级后日志报错及对应动作
以下错误高频出现，别急着回滚，先定位根源：
立即学习“PHP免费学习笔记（深入）”；
-
PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect()：说明代码还在用已移除的mysql_*函数，必须改用mysqli或PDO，不能靠开启旧扩展解决（PHP 8+ 已彻底删除） -
PHP Warning: Use of undefined constant some_const - assumed 'some_const'：PHP 8 默认关闭error_reporting中的E_NOTICE？不，是默认开启了更严格的类型检查，检查是否漏定义常量或变量未加引号 -
Segmentation fault (core dumped)在php -v或php-fpm启动时出现：大概率是某个扩展（如imagick、mcrypt）未重新编译适配新版 PHP，删掉该扩展的.so文件并重装对应版本
如何让日志真正有用——关键配置项检查
很多团队日志开着，但全是空的或只有严重错误，升级排查时等于盲操作。确认这些配置已启用：
-
error_reporting = E_ALL（而非E_ALL & ~E_DEPRECATED & ~E_STRICT） -
display_errors = Off（线上必须关！但log_errors = On必须开） -
log_errors_max_len = 0（避免长错误被截断） -
ignore_repeated_errors = Off（防止同一错误刷屏掩盖其他问题） - 如果用
opcache，升级后务必清空：sudo systemctl restart php*-fpm并确认opcache.revalidate_freq=0临时设为 0，避免缓存旧字节码
升级 PHP 不是改个版本号就完事；日志不是出问题才看，而是升级后第一分钟就要盯住它——特别是 error_log 和 php-fpm.log 里那些看似“只是 warning”的条目，往往是后续 500 错误的伏笔。最常被忽略的是 CLI 和 Web 环境 PHP 实际加载路径不一致，以及扩展未重建导致的静默崩溃。
