在 CentOS 上维护 PHP 服务时，真正能帮你缩小排查范围的，往往不是报错页面本身，而是日志里那几个固定的错误级别代码。它们不仅提示问题是否会让脚本中断，也能反映故障更偏向语法、业务代码，还是 PHP 核心与运行环境。读完这篇，你可以据此快速判断日志优先级，知道哪些问题必须立刻处理，哪些更适合纳入代码清理或环境检查。
CentOS 上先看哪些 PHP 日志
在 CentOS 环境里，PHP 错误日志通常会出现在 /var/log/php-fpm/ 或 /var/log/httpd/ 目录下，具体位置取决于站点是通过 PHP-FPM 还是 Apache 运行。排查时，先确认服务架构，再去对应目录找日志，效率会高很多。
日志里的错误代码可以理解为一层快速分类信息。你不用先把整段报错完全看懂，只要先识别代码级别，就能大致判断这个问题会不会让请求直接失败、属于代码错误还是环境问题，以及是否需要立即修复。
会中断执行的错误：先处理致命级别
如果日志里出现的是致命级别，通常意味着当前请求已经无法继续执行，这类问题应当优先处理。
E_ERROR：致命错误
E_ERROR 表示脚本执行过程中发生了致命错误，程序会立刻终止。这类问题通常不能绕过，发现后应优先修复，否则对应功能基本无法正常使用。
E_PARSE：解析错误
E_PARSE 出现在 PHP 解析语法的阶段，常见原因包括缺少分号、括号不匹配、语法结构写错等。它往往意味着代码还没真正运行就已经失败，因此排查时应先回到最近改动的源码检查语法。
E_COMPILE_ERROR：编译错误
E_COMPILE_ERROR 说明脚本在编译阶段就已经失败，严重程度同样很高。相比普通语法解析错误，它更偏向底层，通常不是简单的运行时变量问题，而是代码本身在装载或编译时就无法成立。
E_RECOVERABLE_ERROR：可恢复错误
E_RECOVERABLE_ERROR 比较特殊。它会导致脚本终止，但理论上可以通过自定义错误处理函数捕获并继续做后续处理，因此比完全不可控的致命错误多了一层兜底空间。不过在实际排查中，仍应把它视为高优先级问题。
不会立刻中断的错误：警告与通知怎么看
另一类常见日志不会马上让脚本停掉，但它们往往是更大问题的前兆。对于线上系统，这些错误不该长期忽视。
E_WARNING：警告错误
E_WARNING 不会终止脚本执行，但可能导致结果异常、功能不完整，或者让页面表现和预期不一致。看到这类日志时，可以把它理解为“程序还能跑，但已经不稳了”。
E_NOTICE：通知错误
E_NOTICE 常见于使用未定义变量、数组下标不存在等场景。它通常不影响当前请求继续执行，但会暴露代码习惯和边界处理不够严谨的问题。对老项目来说，这类日志往往很多，但不代表可以一直放着不管。
E_COMPILE_WARNING：编译警告
E_COMPILE_WARNING 是编译阶段出现的非致命提醒，脚本不一定会直接失败。虽然紧急程度低于编译错误，但它依然说明代码或环境存在值得检查的异常点。
E_CORE_WARNING：核心警告
E_CORE_WARNING 发生在 PHP 核心启动阶段，通常不会立刻影响服务运行，但它反映的是运行环境层面的信号。遇到这类日志时，除了看业务代码，更要留意扩展、配置和启动参数。
核心错误、自定义错误与老项目常见代码
还有一些错误代码不一定天天见，但一旦出现，判断方向要更明确。
E_CORE_ERROR：核心错误
E_CORE_ERROR 表示 PHP 引擎自身在启动或运行关键阶段遇到严重问题。这类故障通常不是单靠改业务代码就能解决，更可能与环境配置、扩展加载状态或运行组件有关。
E_USER_ERROR / E_USER_WARNING / E_USER_NOTICE
这三类错误由开发者通过 trigger_error() 主动触发，属于业务代码里的自定义错误体系。
E_USER_ERROR：自定义致命错误，通常用于明确中止某段流程。E_USER_WARNING：自定义警告，不会致命，但说明业务逻辑检测到了异常状态。E_USER_NOTICE：自定义提示，常用于调试、记录状态或输出开发阶段信息。
如果日志里大量出现这几类代码，排查重点就不该只放在 PHP 环境本身，而要回到项目代码，查看哪里主动调用了 trigger_error()。
E_STRICT：严格标准错误
E_STRICT 主要用于提示代码规范性问题，例如方法签名不兼容等。这类信息在老项目中更常见。需要注意的是，它在 PHP 7 之后已经弃用，因此如果你还在日志里看到它，往往说明项目代码或历史运行习惯比较旧，升级时要额外留意兼容性。
拿到错误代码后，应该怎样判断优先级
实际处理日志时，可以先按三步判断：
- 先看它是否会终止脚本，例如
E_ERROR、E_PARSE、E_COMPILE_ERROR、E_RECOVERABLE_ERROR这类通常都要优先处理。 - 再看问题发生在代码层还是核心层。像
E_WARNING、E_NOTICE更偏应用代码；E_CORE_ERROR、E_CORE_WARNING更偏 PHP 运行环境。 - 最后确认是不是业务代码主动触发。如果是
E_USER_ERROR、E_USER_WARNING、E_USER_NOTICE，就应回到项目里的trigger_error()调用点继续查。
如果日志里出现本文没有覆盖的错误级别，或者你需要进一步确认具体修复方式，最稳妥的做法仍然是结合 PHP 官方文档继续核对说明。对 PHP 排障来说，看懂错误代码不是终点，但它通常是最快进入正确排查方向的起点。
