PHP 8.0升级后错误不显示主因是log_errors默认为0且error_log路径失效，需检查php.ini中log_errors=1、error_log路径可写，并确认Nginx/PHP-FPM或框架日志配置是否覆盖。
PHP 8.0 升级后错误不显示，不是代码没报错，而是日志根本没写进去或压根没启用。
确认 PHP 错误日志路径是否生效
升级后 php.ini 可能被重置或加载了另一个配置文件，error_log 设置可能失效。先查真实加载的配置：
- 运行
php --ini看Loaded Configuration File路径 - 在该
php.ini中搜索error_log，若为空或注释掉，PHP 会退回到系统日志（如/var/log/apache2/error.log或/var/log/php-fpm/www-error.log） - 执行
php -i | grep error_log，确认输出的路径是否可写、是否存在 - 如果用的是 Nginx + PHP-FPM，还要检查
www.conf中的php_admin_value[error_log]是否覆盖了 php.ini 的设置
为什么开了 display_errors 还看不到错误？
因为 display_errors = On 只控制“是否输出到页面”，和“是否写入日志”是两回事。很多升级后的问题出在日志开关被关了：
-
log_errors默认值在 PHP 8.0 是"0"（即关闭），必须显式设为"1" -
error_reporting在 PHP 8.0.0+ 默认是E_ALL，但若你在代码里调用了error_reporting(0)或旧配置残留，仍会屏蔽日志 - 验证当前值：运行
php -r "echo error_reporting() . PHP_EOL; echo ini_get('log_errors') . PHP_EOL;"，两个输出都应是非零值 - 注意：某些主机环境（如 cPanel）会强制覆盖
log_errors，需在用户级.user.ini或php_flag log_errors on（Apache）中补救
ThinkPHP 8.0 或 WordPress 等框架下日志“消失”的真实原因
框架常拦截并重定向错误，导致你查系统日志却找不到任何记录：
立即学习“PHP免费学习笔记（深入）”；
- TP8.0 默认只在
runtime/log/写日志，前提是config/app.php中'record' => true且目录可写；ls -ld runtime/log/若显示权限不足（如 root:root），Web 进程（www-data/nginx）就写不进去 - WordPress 升级 PHP 后白屏，
wp-config.php里没开define('WP_DEBUG', true); define('WP_DEBUG_LOG', true);，错误全被吞掉，连wp-content/debug.log都不会生成 - 用
tail -f监控日志时，记得同时触发一次报错行为（比如访问一个不存在的路由或错语法的模板），否则日志文件可能空着不动 - 某些 Docker 环境中，
/tmp或runtime/挂载为只读，需在容器启动时加chmod -R 755 /app/runtime类命令修复
最易被忽略的一点：PHP 8.0.12 存在已知 bug（Bug #81591），即使配置全开，也可能只记录第一个错误就终止——此时看日志永远只有半截，必须升级到 8.0.13+ 或临时关掉 ignore_repeated_errors。
