别再把报错往页面上扔了：PHP错误日志配置实战指南

线上环境突然白屏，后台翻遍代码却找不到致命错误在哪。这种“盲猜式”排查，每个维护过PHP项目的开发者都经历过。很多人习惯把错误直接吐在浏览器里调试，但一上线就默默关掉显示。问题恰恰出在这里：关掉显示不等于解决问题，不记录错误的关闭等于掩耳盗铃。一套靠谱的PHP错误日志配置，不是机械地改几行参数，而是给应用装上实时运转的“行车记录仪”。

配置文件层面的调整是地基。打开 php.ini 或服务商提供的 .user.ini，重点盯住核心开关。本地开发阶段，建议开启 display_errors = On 并配合 log_errors = On，让错误同时出现在屏幕和日志里，方便快速对照。进入生产环境后，必须彻底反转：display_errors = Off 绝不能妥协，前端页面暴露完整堆栈会直接泄露架构细节；log_errors = On 则是安全底线，所有异常必须强制落地。至于 error_reporting = E_ALL，尽量保持全量捕获，别为了界面干净提前屏蔽Notice。许多内存泄漏和数据格式错乱，正是从被忽略的弱类型警告里悄悄滋生的。

错误写入哪本账册同样讲究。error_log 参数需明确指定日志路径，强烈建议避开网站根目录或临时文件夹。生产环境可统一归集至 /var/log/php/app_error.log，并通过命令手动创建文件并收紧权限：chmod 640 /path/to/file，确保仅Web运行用户可写，其他账户不可读。权限配错只会导致程序静默失败，查无日志比报错更可怕。改动完成后，务必重启 PHP-FPM 使新路径生效，这一步常被遗漏，导致配置形同虚设。

日志体积膨胀是迟早的事，不清理就会拖垮磁盘性能。手动删文件既粗暴又容易误伤正在写入的句柄。务必引入 logrotate 机制进行自动化轮转。设定每日切割策略，单文件超过 50MB 强制切分，保留过去 7 天的切片并压缩归档。配合定时任务释放空间，能省去后期无数次紧急清盘的焦虑。如果是容器化部署，直接把日志管道重定向到 stdout/stderr 交由宿主机采集，反而更符合云原生规范。

标准输出往往混杂着框架底层的调试噪音，长时间积累会掩盖真实故障。当项目接入自定义错误处理器后，可以追加过滤层。例如拦截静态资源 404 请求产生的 Notice，或将高频非致命警告分流至独立文件。主日志保持纯净，真正阻断请求的 Fatal 和 Parse Error 才会浮出水面。配合 grep 或简单的日志分析脚本，日常巡检时间能缩短大半。

错误日志不是一次性配置的摆设，它需要定期回顾与策略微调。养成查看昨日异常峰值的习惯，结合监控平台设置严重级别告警，把被动救火转化为主动排雷。把底层记录逻辑理顺，开发节奏自然从容。代码跑得再快，也抵不过一次精准的日志回溯。