php报错未显示或未记录的主因是error_reporting为0、log_errors关闭、日志路径无写权限或被fpm/cli配置覆盖；需用ini_get诊断四参数并验证日志路径权限。
PHP 报错时别急着改代码，先确认错误是否真的被记录、记录在哪、有没有被屏蔽——绝大多数“找不到错误”的情况，其实是日志没开、路径不对、或 error_reporting 被设成了 0。
怎么看 PHP 当前的错误报告级别和日志路径
直接在出问题的脚本开头加一段诊断代码，比翻配置文件快得多：
echo 'error_reporting: ' . ini_get('error_reporting') . "\n";
echo 'display_errors: ' . ini_get('display_errors') . "\n";
echo 'log_errors: ' . ini_get('log_errors') . "\n";
echo 'error_log: ' . ini_get('error_log') . "\n";
关键看这四行输出：
-
error_reporting为0表示所有错误都被静默吞掉，需设为E_ALL或E_ALL & ~E_NOTICE -
display_errors开启（On）才可能在浏览器看到报错，但线上环境必须关 -
log_errors必须是On，否则不会写日志 -
error_log显示日志实际写入位置，常见值有：/var/log/php_errors.log、/var/log/apache2/error.log（Apache）、syslog（系统日志）、或为空（此时默认写进 Web 服务器错误日志）
常见错误日志不生成的三个硬坑
即使配置看起来没问题，以下情况仍会导致日志“消失”：
立即学习“PHP免费学习笔记（深入）”；
- Web 服务器用户（如
www-data或apache）对error_log指定路径无写权限 —— 用ls -l /var/log/php_errors.log看属主，用sudo chown www-data:www-data /var/log/php_errors.log修复 - PHP 运行在 FPM 模式下，
php.ini里设了error_log，但 FPM 的www.conf里又覆盖了php_admin_value[error_log]，以 FPM 配置为准 - 用了
try/catch却没 re-throw 或没记录，比如catch (Exception $e) { echo "出错了"; }—— 这类错误根本不会进 PHP 错误日志，得靠你自己写error_log($e->getMessage(), 3, '/path/to/log');
快速触发并验证错误日志是否生效
别等业务代码出问题，主动制造一个可复现的 Notice 来测试：
<?php // 强制触发一个未定义变量 Notice echo $undefined_var; ?>
然后立刻执行：
- 如果
display_errors = On，页面会直接显示Notice: Undefined variable: undefined_var - 如果
log_errors = On，就去ini_get('error_log')指向的文件末尾tail -f /var/log/php_errors.log查看是否追加了对应行 - 若没出现，说明日志链路断在某处：权限、路径、FPM 覆盖、或 Apache/Nginx 把错误吞给了自己的 error log
CLI 模式下 PHP 报错不进常规日志？
命令行运行 PHP 脚本（如 php script.php）默认不读取 Web 服务器的 php.ini，而是用 CLI 专属配置：
- 运行
php --ini查看 CLI 加载的是哪个php.ini - CLI 下
display_errors默认是On，但log_errors默认是Off，必须手动开启 - CLI 日志路径建议显式指定，避免和 Web 混用：在脚本开头加
ini_set('error_log', '/tmp/cli_errors.log'); - 注意：CLI 不受 Web 服务器用户限制，但要确保当前 shell 用户对日志路径有写权限
真正卡住人的往往不是语法错误本身，而是错误没露头——查日志前先确认 log_errors 是 On、路径可写、且没被更高层配置覆盖。FPM、CLI、Apache 模块三套环境的配置彼此独立，切勿假设它们一致。
