线上环境可以记录详细错误，但不要把错误细节直接展示给用户。
一、现场复盘：display_errors 开着会把路径露出来
线上页面突然出现 Warning、Notice，最尴尬的不是页面难看，而是错误里经常带真实路径、文件名、行号，甚至能顺手暴露一段业务逻辑。
测试环境为了调试方便，打开 display_errors 很正常。但这个配置如果被带到线上，用户看到的就不是友好的业务提示，而是一整段 PHP 报错。
排查时先看三处：
· php.ini 里的 display_errors。
· 项目启动代码里有没有 ini_set('display_errors', 1)。
· 框架环境变量有没有把调试模式打开。
线上建议让页面只返回业务错误，详细错误交给日志。这样用户不会看到内部路径，开发也能继续定位问题。
二、配置组合：error_reporting() 负责级别，error_log 负责落点
error_reporting() 管的是错误级别，常见做法是开发环境开到 E_ALL，让小问题尽早暴露。线上也可以记录足够多的错误，但展示层要关掉。
一套比较稳的线上思路是：
· error_reporting 设置为 E_ALL 或符合团队规范的级别。
· display_errors 设置为 Off。
· log_errors 设置为 On。
· error_log 指向明确、可写、会被清理的日志路径。
error_reporting = E_ALL display_errors = Off log_errors = On error_log = /var/log/php/error.log
如果项目里临时用了 ini_set()，上线前要扫一下。配置文件写得再漂亮，被代码里一行覆盖掉，排查会很绕。
三、日志没出来：优先查 error_log 路径和权限
页面没展示错误，但日志也查不到，这种情况很常见。它不一定代表没有错误，可能是日志压根没写进去。
建议按这个顺序看：
· error_log 配的路径是否存在。
· PHP-FPM 运行用户对目录有没有写权限。
· 磁盘空间是否已满。
· 日志是否被容器或进程管理器接管到了别的位置。
· 改完 php.ini 后有没有重载 PHP-FPM。
php -i | grep error_log tail -f /var/log/php/error.log
容器环境里尤其要留意，很多镜像会把错误写到标准错误输出。这个时候你在磁盘文件里找不到日志，要去容器日志或平台日志面板里看。
四、发布检查：错误能被发现，但不能被用户看到
错误处理不是只配一次就完事。每次发布、迁移服务器、换容器镜像，都可能把环境配置带偏。
上线前我会固定查这几项：
· 访问一个故意触发错误的测试路由，确认页面不展示内部细节。
· 查日志是否能记录到文件名、行号、错误级别。
· 确认日志文件会被轮转，避免把磁盘写满。
· 关键错误接入告警，不靠人工翻日志。
· 调试开关只在开发环境生效。
PHP 错误日志这块不复杂，但很容易被忽略。真正要盯的是两件事：用户看不到内部细节，开发能快速找到现场。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
