PHP 8.5 中 error_log() 本身无变化，但因 TypeError、ValueError 等转为可捕获 Throwable，开发者更常在 try-catch 中主动调用它记录错误；推荐使用 message_type=3 写入绝对路径文件，需确保目录存在、权限正确，并手动添加换行符。
PHP 8.5 中 error_log() 函数本身没有行为变化，但错误捕获更彻底——原本会直接崩溃的 TypeError、ValueError 现在默认转为可 catch 的 Throwable，所以你更可能在 try-catch 块里主动调用 error_log() 记录它们，而不是等 PHP 自动写入系统日志。
直接写文件：用 message_type = 3 最稳妥
这是生产环境最常用的方式，不依赖邮件配置或 SAPI 日志链路，可控性强。
-
error_log()不会自动加换行符，记得在$message末尾手动加"\n"，否则所有日志会挤在一行 - 目标路径必须是绝对路径，且 Web 进程用户（如
www-data或nginx）有写权限；/tmp/虽方便但不推荐用于生产，优先选/var/log/myapp/这类独立目录 - 文件不会自动创建父目录，
/var/log/myapp/error.log要求/var/log/myapp/已存在并可写，否则调用失败且无提示 - 示例：
error_log("[" . date('Y-m-d H:i:s') . "] DB query failed: " . $pdo->errorInfo()[2] . "\n", 3, '/var/log/myapp/db_errors.log');
配合异常捕获：PHP 8.5 的典型用法
PHP 8.5 把多数致命错误降级为可捕获异常，error_log() 常出现在 catch 块中，替代过去只能靠全局处理器才能拿到的日志上下文。
- 不要只记录
$e->getMessage()，加上$e->getTraceAsString()才能定位到具体哪行代码出问题 - 避免在
catch里只做echo或静默吞掉异常；至少调用一次error_log()，否则错误就消失了 - 注意
error_log()返回布尔值，失败时返回false，可在开发期加简单判断：if (false === error_log($logMsg, 3, $logFile)) { error_log("Failed to write log to $logFile"); } - 示例：
try { $result = json_decode($input, flags: JSON_THROW_ON_ERROR); } catch (JsonException $e) { error_log("JSON decode failed: " . $e->getMessage() . " in " . $e->getFile() . ":" . $e->getLine() . "\n", 3, '/var/log/myapp/json_errors.log'); throw $e; // 重新抛出，不中断业务逻辑 }
别踩 message_type = 0 的坑
这个值看似“默认”，实则最不可控：它把日志甩给 PHP 配置里的 error_log 指令，而该指令在 CLI、FPM、Apache 模块下可能指向完全不同的文件，甚至被覆盖。
立即学习“PHP免费学习笔记（深入）”；
- FPM 场景下，
php.ini的error_log可能被 pool 配置中的php_admin_value[error_log]覆盖，你查phpinfo()看到的和实际写入的不是同一个路径 - 如果同时启用了
log_errors = Off，哪怕你调用error_log($msg, 0)，什么也不会写入——它受全局开关控制 - 调试时想快速验证日志是否生效？别用
0，直接上3指定文件路径，眼见为实
真正麻烦的从来不是怎么写一行 error_log()，而是确保每条日志都带时间戳、上下文、可追溯，并且日志文件本身不因权限、路径、磁盘满而失效。PHP 8.5 让错误更“听话”了，但日志能不能留下痕迹，还得看这三步：路径对不对、权限够不够、换行加没加。
