关键在于精准过滤日志内容：生产环境应设error_reporting=e_all & ~e_notice & ~e_deprecated & ~e_strict，保留e_deprecated以预警升级风险，确保error_log路径存在且php进程有写权限，并用register_shutdown_function捕获fatal error。
想靠 error_log 快速发现代码隐患，关键不是“有没有日志”，而是日志里有没有真正值得你警觉的信息——低级别提示（如 E_NOTICE）混在大量无害输出中，反而会掩盖真正的风险点。
只记录该关注的错误类型
默认 error_reporting = E_ALL 会把未定义变量、空数组取键这类提示全记下来，日志迅速膨胀且干扰严重。生产环境应主动过滤：
- 设为
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT—— 这是兼顾可维护性与简洁性的实用底线 -
E_DEPRECATED建议保留：它不报错，但明确告诉你“这个函数下个PHP版本就没了”，是升级前最重要的预警信号 - 别只在脚本里用
ini_set()修改，要确认没被框架或 PHP-FPM 的php_admin_value[error_reporting]覆盖
确保日志文件能真正写进去
日志为空？权限拒绝？常见原因不是配置错了，而是路径或权限没到位：
- 先执行
echo ini_get('error_log');确认当前生效路径，常见位置有/var/log/php/error.log、/usr/local/var/log/php/error_log或项目根目录下的php_error.log - 路径必须存在，且 PHP 进程用户（如
www-data或nginx）有写权限：mkdir -p /var/log/php && touch /var/log/php/error.log && chown www-data:www-data /var/log/php/error.log - SELinux 启用时（如 CentOS/RHEL），可能静默拦截：临时运行
setenforce 0测试，若日志立刻出现，说明需加策略setsebool -P httpd_can_network_connect 1
捕获那些常规方式看不到的致命错误
set_error_handler 对 E_ERROR、E_PARSE、E_COMPILE_ERROR 完全无效——它们发生时 PHP 已放弃执行上下文。必须用关机函数兜底：
- 在入口文件最开头注册：
register_shutdown_function(function () { $e = error_get_last(); if ($e && in_array($e['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR])) { error_log(sprintf("[FATAL] %s in %s on line %d", $e['message'], $e['file'], $e['line']), 3, '/var/log/php/fatal.log'); } }); - 注意
error_get_last()可能返回null，务必判断后再处理 - 建议单独存为
fatal.log，和普通错误日志分离，便于监控告警
用命令行快速筛出隐患线索
别从头翻日志。Linux 下几条命令就能定位高频问题：
-
tail -f /var/log/php/error.log：实时盯住新错误，复现问题时最直观 -
grep "Fatal error\|Parse error\|Uncaught" /var/log/php/error.log：抓致命和语法错误 -
grep "Deprecated" /var/log/php/error.log | head -20：查近期弃用警告，提前规避升级风险 -
grep "Warning" /var/log/php/error.log | grep -v "fopen\|file_get_contents" | wc -l：排除常见IO警告后，统计其他警告数量，过高说明逻辑异常频发
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
