PHP报错完整流程：从日志定位到代码修复的实操路径

线上PHP报错最烦人的不是修，而是找。页面一片空白或者只抛个500，这时候最忌讳对着代码瞎猜。我的习惯是：先让系统把错误吐干净，再按日志线索决定是改配置、调权限还是动代码。

让PHP开口：错误报告怎么开

排错前先把错误报告拉满。开发环境直接修改php.ini，将display_errors设为On，error_reporting开到E_ALL，同时指定一个容易找的日志路径，比如/var/log/php_errors.log。生产环境则必须关掉display_errors，只留log_errors，避免敏感信息暴露。

如果线上临时需要暴露错误，在代码入口用ini_set配合error_log输出，但发版时一定要清理。很多人忽略了日志目录的写入权限，php-fpm和Web用户必须拥有写入权限，SELinux或AppArmor有时也会拦截，排查时记得顺手检查。

日志是现场：别只看PHP自身的日志

PHP报错不一定只出现在php.ini指定的error_log里。Apache的error.log、Nginx的error.log，甚至php-fpm的slow log都可能藏着线索。建议开几个终端同时tail -f，复现问题时观察哪边先输出关键字。

看到报错先认级别。Fatal Error直接阻断执行，优先处理；Warning和Notice虽然不一定致命，但往往是隐患信号。如果日志完全没动静，先确认php-fpm进程是否存活，再检查请求是否真的走到了该节点，避免在错误方向上浪费时间。

常见报错快速对号入座

Parse error最简单，日志会精确到行号，多半是少了个分号或括号不匹配。本地提交前跑一遍php -l做语法检查，能避免低级失误。

Call to undefined function先想扩展装没装，比如gd、mbstring、redis。再检查自动加载，执行Composer dump-autoload往往有奇效。如果是自定义函数找不到，多半是文件包含顺序或命名空间问题。

Allowed memory exhausted通常是循环内内存未释放，或者一次性加载了太大数据集。临时调高memory_limit能续命，但根本办法是分批读取、及时unset大对象。

Maximum execution time exceeded先别急着调时间。用microtime打点或xdebug profiling抓出慢在哪，是数据库拖死还是死循环，找到真凶再决定怎么修。

深坑用Xdebug：别靠echo打天下

复杂逻辑错误日志里看不出来时，上Xdebug。装好后在php.ini开启debug模式，IDE里下断点逐步跟。这比到处var_dump干净得多，也不会把敏感数据留在页面上。如果线上没法直接调试，可配置为trigger模式，只有带特定Cookie才启动，避免影响正常流量。

代码排查的辅助技巧

报错信息模糊时，采用逐段注释法：将可疑代码一半一半注释掉，观察错误是否消失，快速缩小范围。配合try-catch包裹关键逻辑，把Exception详情写进日志，比默认堆栈更可控。

临时输出变量可以使用var_dump，但发版前务必全局清理。曾发生过线上把数据库密码dump在页面上的事故，排查输出要格外小心。

先止血再手术：线上恢复的临时手段

业务受影响时优先恢复服务。新代码引发的问题直接回滚最稳妥。如果必须临时屏蔽某个非致命报错，用set_error_handler接管，但务必把原始错误写进日志，否则后续无法追溯根因。