PHP error_log不生效主因是配置文件路径错误、运行时被覆盖、权限不足或日志被框架禁用；需确认真实php.ini路径、开启log_errors、确保进程用户有目录写+执行权限，并避免相对路径。
php.ini 中 error_log 配置不生效的常见原因
直接改 error_log 配置项却没日志写入，大概率是 PHP 没读到你改的那个配置文件，或者被运行时代码覆盖了。CLI 和 Web（如 Apache/FPM）环境用的 php.ini 路径通常不同，php --ini 和 phpinfo() 显示的才是真实加载路径。
- 检查是否在错误的
php.ini里修改——FPM 下改 CLI 的配置毫无作用 -
display_errors = On不影响日志写入，但会干扰判断：关掉它，专注看日志文件是否有新增 - 某些框架（如 Laravel、Symfony）或 CMS（如 WordPress）会在启动时调用
error_reporting(0)或ini_set('log_errors', '0')，直接禁用日志 - 目录权限问题：PHP 进程用户（如
www-data或nginx）必须对目标日志路径有写权限，且父目录可执行（chmod 755目录）
运行时用 ini_set 写入指定日志文件更灵活
比起全局配置，用 ini_set() 在脚本开头动态设定，能避免多项目共用同一日志，也方便按模块隔离。但它只对当前请求/进程有效，且必须在任何错误触发前调用。
-
ini_set('log_errors', '1')必须显式开启，否则error_log路径设了也不写 -
ini_set('error_log', '/var/log/myapp/php_errors.log')路径需绝对，相对路径行为不可靠 - 若同时用了
set_error_handler()，默认错误不会进error_log，除非你在 handler 里手动调用error_log($message, 3, $file) - FPM 下注意
catch_workers_output = yes可能把 stderr 输出也混进日志，建议关掉或单独配置slowlog
error_log() 函数写日志时的路径与权限陷阱
用 error_log() 函数写入自定义文件，看似简单，但第三个参数为 3 时，路径处理和权限检查比想象中严格。
-
error_log('msg', 3, '/tmp/app.log')：路径必须可写，且 PHP 进程用户需有该路径的「写+执行」权限（Linux 下目录无 x 权限无法进入） - 不要用
./logs/error.log这类相对路径——工作目录不确定，Web 请求下通常是文档根目录，CLI 下是执行命令的位置 - 日志文件不会自动创建父目录，
/var/log/myapp/不存在时会静默失败，得提前mkdir -p /var/log/myapp && chown www-data:www-data /var/log/myapp - 高并发下多个进程同时写同一文件可能丢日志，生产环境建议配合
syslog（error_log('msg', 4)）或用 Monolog 等库做异步/队列写入
Apache + PHP-FPM 场景下日志实际归属要分清
Web 环境下，你以为的“PHP 错误日志”可能混着 Apache 的 ErrorLog、FPM 的 error_log、以及 PHP 自己的 error_log，三者完全独立。
立即学习“PHP免费学习笔记（深入）”；
- Apache 的
ErrorLog（如/var/log/apache2/error.log）只记录模块级错误，PHP 语法错误一般不出现这里 - FPM 的
error_log（如/var/log/php-fpm.log）记录 FPM 进程自身问题（启动失败、子进程崩溃），不是 PHP 脚本错误 - 真正要捕获
Notice/Warning的，必须确保 PHP 层的log_errors = On且error_log指向明确文件 - 验证是否生效：故意写一行
trigger_error('test', E_USER_WARNING)，然后tail -f对应文件看输出
phpinfo() 看真实值，再 ls -l 看路径权限，最后用 strace -e trace=write -p $(pgrep php-fpm) 观察是否真有写入系统调用。 
