Ubuntu PHP日志故障排查

在排查PHP日志问题之前，有个关键点容易被忽略——不同SAPI模式下的配置文件和日志路径可能是分开的。这意味着，当你看到页面报错但日志文件空空如也时，往往不是PHP没有记录错误，而是查错了地方。先列个速查表，方便查阅。

要确认当前真正加载的是哪个php.ini，可以用 php -i | grep 'Loaded Configuration File' 来定位。再通过 grep -i error_log /etc/php/*/fpm/php.ini /etc/php/*/apache2/php.ini 直接检索具体配置值。别忘了，apache2与fpm可能指向完全不同的ini文件，这点很多人踩过坑。

正确开启与调整日志级别

定位到对应的php.ini后，需要确保几个关键配置被正确打开。对于生产环境，建议这样设置：

• error_reporting = E_ALL —— 所有错误都要记录
• log_errors = On —— 开启日志记录
• display_errors = Off —— 不要显示到页面上

日志文件路径可以自定义，比如 error_log = /var/log/php_errors.log，但务必确保目录对www-data用户可写。如果使用PHP-FPM，还需要在 /etc/php/7.x/fpm/pool.d/www.conf 中设置 catch_workers_output = yes，否则部分脚本错误不会进入主日志。

配置修改后，记得重启相应服务：Apache用 sudo systemctl restart apache2，PHP-FPM用 sudo systemctl restart php7.4-fpm，Nginx同理。验证方法也很简单——创建一个探针文件 /var/www/html/info.php，内容写 ，然后通过浏览器访问，确认 error_log、error_reporting 和 log_errors 的实际值已经生效。

常见故障与修复清单

遇到页面空白或只显示500错误，最直接的做法是优先查看Apache或Nginx的错误日志，再加一份PHP-FPM日志，通常能快速定位到语法错误、致命问题或池配置异常。

如果发现日志文件为空或没有新日志写入，先检查 log_errors = On 是否真的开启了，error_log 路径是否有效。特别要注意目录权限，比如 /var/log/php/ 是否对 www-data 可写。对于FPM场景，catch_workers_output = yes 这个配置很容易被忽略，但恰恰是它决定了部分输出能否进入主日志。

权限与所有权问题也经常让人头疼。Web目录和日志目录建议归属于 www-data:www-data，权限按最小原则设为755或644。可以用 sudo chown -R www-data:www-data /var/www/html 和 sudo chmod -R 755 /var/www/html 来快速调整。

扩展缺失导致的报错，比如“调用未定义函数”，通常安装对应扩展就能解决。举个例子：sudo apt-get install php-mbstring，安装后记得重启 php7.4-fpm 或 apache2。如果修改了配置但没生效，先确认你改的是不是正确的SAPI配置文件——apache2、fpm、cli各有各的ini，改对了还要重启对应服务才行。

高效排查命令与脚本

实时跟踪多路日志源时，可以用 sudo tail -f 同时追踪多个文件，比如 /var/log/apache2/error.log、/var/log/nginx/error.log 和 /var/log/php7.4-fpm.log，配合tmux分屏操作效率更高。

要快速定位首次报错或特定模块问题，可以用grep进行关键字检索：sudo grep -i "error|fatal|exception" /var/log/php7.4-fpm.log，或者针对“调用未定义函数”这类特定错误单独检索。

想在代码中主动写入日志来辅助定位业务层问题，可以直接调用 error_log("业务步骤失败，用户ID=" . $uid, 0)，其中参数0表示使用php.ini配置的error_log路径。

最后必须提醒一句：生产环境下，排查完成后务必保持 display_errors = Off，仅保留 log_errors = On，这是防止敏感信息外泄的基本防线。