error_log()默认不写自定义文件，仅当指定模式3或显式传路径时才绕过php.ini配置；需确保目录存在、权限正确、用绝对路径，并手动加换行符。
error_log() 写不到自定义文件？先看参数模式
PHP 8.3 的 error_log() 默认不写入你传的路径，而是走 error_log ini 配置项（比如 Apache 的 error.log）。它只在明确指定文件路径 + 模式 3 或显式传字符串时才绕过全局配置。
常见误用：
-
error_log("msg")→ 写进 php.ini 里error_log = /var/log/php_errors.log指定的位置，不是当前目录 -
error_log("msg", 3, "/tmp/my.log")→ 正确：模式 3 强制写文件，但需确保/tmp可写且 PHP 进程有权限 -
error_log("msg", 0, "/tmp/my.log")→ 错误：模式 0 是“系统日志”，第三个参数被忽略，仍走 ini 配置
推荐写法：error_log($msg, 3, $file) 或直接 error_log($msg, 3, "/var/log/app.log")，避免歧义。
php.ini 配置生效但日志为空？检查三个硬性条件
即使 log_errors = On、error_log = /var/log/php_errors.log、error_reporting = E_ALL 全部设好，日志仍可能为空——因为缺了底层支撑。
立即学习“PHP免费学习笔记（深入）”；
必须确认：
-
/var/log/php_errors.log所在目录存在，且 Web 服务用户（如www-data、nginx）对该路径有w权限；仅文件可写不够，父目录也得可写 - PHP 进程没被 SELinux 或 AppArmor 限制（CentOS/RHEL 常见），可用
ausearch -m avc -ts recent | grep php查拦截记录 - 错误确实发生了：
trigger_error("test", E_USER_WARNING)是最干净的测试方式，比file_get_contents("/nonexist")更可控
别依赖页面报错来判断日志是否启用——display_errors = Off 时页面空白，但日志该写还得写。
高并发下日志错乱或丢失？别手写 file_put_contents
用 file_put_contents($file, $line, FILE_APPEND | LOCK_EX) 自建日志函数看似简单，但在 PHP-FPM 多 worker 场景下仍有风险：
-
LOCK_EX只对单次写有效，如果多条日志几乎同时触发，仍可能因调度延迟导致换行错位（比如两行日志挤成一行） - 频繁调用
file_put_contents会引发大量系统调用，压测时 I/O 成瓶颈 - 没处理时区：
date('Y-m-d H:i:s')若未调date_default_timezone_set("Asia/Shanghai")，时间戳和系统日志对不上
更稳做法是直接用 error_log($msg, 4) 发到 syslog——Linux 下自动进 /var/log/syslog 或 /var/log/messages，由 rsyslog 或 systemd-journald 统一做缓冲、轮转和权限管理，PHP 层零维护成本。
监控告警链路断在哪？从日志源头开始验证
ELK 或 Zabbix 告警没触发，第一反应不该是查 Logstash 配置，而是确认日志是否真的落盘：
- 执行
tail -f /var/log/php_errors.log同时触发一个trigger_error()，看是否实时出现 - 若无输出，改用
strace -e trace=openat,write -p $(pgrep php-fpm)抓 PHP 进程实际打开/写入的文件路径 - 若写到了
/var/log/syslog，但 ELK 没采集到，说明问题在 Filebeat 日志路径配置（如paths: ["/var/log/syslog"]）或 grok filter 匹配失败
PHP 8.3 不再默认开启 opcache.save_comments，但这对日志无影响；真正容易被跳过的，是 error_log 路径权限校验和 syslog 接收端是否启用 UDP/TCP 监听——这两处一错，整条链路静默失效。
