log_errors=On但日志无内容的最常见原因是PHP未加载修改的php.ini文件，需通过php --ini和php -i确认实际生效配置，并检查PHP-FPM独立配置、权限设置、error_reporting级别及pool级覆盖等多层因素。
log_errors=On 但日志文件没内容
最常见原因是 PHP 没真正加载你改的 php.ini。别急着重装，先确认当前生效配置：运行 php --ini 看 Loaded Configuration File 路径，再用 php -i | grep "log_errors" 检查实际值。很多情况下你改的是 CLI 的 php.ini，而 Web 请求走的是 PHP-FPM 的独立配置（比如 /etc/php/8.2/fpm/php.ini），两者完全不互通。
还要注意：如果用了 ini_set('log_errors', '1')，它在某些 SAPI（如 Apache mod_php）下会被忽略——PHP 官方文档明确写了该指令是 PHP_INI_SYSTEM 级别，只能在 php.ini 或 .htaccess（Apache）中设，不能用代码覆盖。
- 检查
phpinfo()页面里Loaded Configuration File和Additional .ini files parsed两栏 - 确认
log_errors行显示为On，不是Off或no value - 若用 Nginx + PHP-FPM，记得重启
php-fpm服务，不是只重启 nginx - 用
ps aux | grep php-fpm看进程是否已用新配置启动
日志路径写对了却没权限写入
error_log = /var/log/php/error.log 这行看着没问题，但 PHP 进程（通常是 www-data、nginx 或 php-fpm 用户）可能根本没权限往该目录写文件。错误不会报给你看，只会静默丢弃——这也是“不生效”的典型假象。
验证方法很简单：sudo -u www-data touch /var/log/php/test.log。如果提示 Permission denied，就坐实了权限问题。
立即学习“PHP免费学习笔记（深入）”；
- 确保目录存在：
sudo mkdir -p /var/log/php - 赋权给 PHP 运行用户：
sudo chown www-data:www-data /var/log/php（替换成你实际的用户，如nginx） - 设宽松但够用的权限：
sudo chmod 755 /var/log/php（别用 777） - 避免写根目录下的
/var/log/php_errors.log，有些系统 SELinux 或 AppArmor 会拦截
display_errors=Off 导致你以为没错误
很多人调 log_errors 是为了抓生产环境错误，但忘了关掉 display_errors 后，页面一片空白或 500，根本看不出错在哪。这时候你盯着空日志怀疑配置失效，其实错误早发生了，只是没被记录——因为 error_reporting 太低，或者被脚本里某处 error_reporting(0) 覆盖了。
关键点：log_errors 只决定“要不要记”，而 error_reporting 决定“哪些错误值得记”。两者必须同时生效才有效果。
- 检查
php -i | grep error_reporting输出是否匹配预期（如E_ALL & ~E_NOTICE） - 搜索项目代码里有没有
error_reporting(0)或ini_set('error_reporting', '0') - 注意框架（如 Laravel、Symfony）可能在启动时重置
error_reporting，得在框架初始化前就设好 - 临时加一行
error_log("test log entry");到入口脚本，确认日志路径和权限真能写
PHP-FPM pool 配置覆盖了全局设置
当使用 PHP-FPM 时，每个 pool（如 www.conf）可以单独定义 php_admin_value[log_errors] 或 php_flag[log_errors]。这类设置优先级高于 php.ini，而且一旦设成 off，连 ini_set 都无法覆盖。
打开你的 pool 配置（通常在 /etc/php/*/fpm/pool.d/www.conf），搜 log_errors 和 error_log。如果看到类似 php_flag[log_errors] = off，哪怕 php.ini 写了 On 也白搭。
- 删掉或注释掉 pool 文件里的
php_flag[log_errors]行 - 如果要保留 pool 级控制，改成
php_flag[log_errors] = on并配好对应php_admin_value[error_log] - 改完必须
sudo systemctl reload php*-fpm（reload 比 restart 更稳妥） - reload 后立刻跑
php-fpm -t验证配置语法
真正卡住人的往往不是配置本身，而是多层配置叠加后的优先级混乱，以及权限和用户上下文被忽略。动手前先 php -i 和 ps aux 看清实际运行态，比反复改配置有用得多。
