在 CentOS 环境里，PHP 报错往往不是“看不懂”，而是信息太杂，不知道该先处理哪一种。判断错误级别、定位对应日志文件，再结合文件路径、行号和错误描述去排查，通常就能很快分清这是代码问题、扩展配置问题，还是资源限制问题。
这篇文章把 PHP 日志里常见的错误类型按处理优先级重新梳理一遍。你可以据此判断哪些报错会直接中断脚本，哪些虽然还能运行但已经埋下隐患，以及遇到超时、内存耗尽这类高频问题时该从哪里下手。
先确认 PHP 错误日志在哪
在 CentOS 系统中，PHP 错误日志的位置取决于你的运行方式和 Web 服务器类型，常见路径包括：
/var/log/php-fpm/error.log：PHP-FPM 环境/var/log/httpd/error_log：Apache 环境/var/log/nginx/error.log：Nginx 环境
日志里的错误码通常以 E_ 开头，不同前缀对应不同严重程度。排查时不要只盯着错误名本身，更要看清日志里的文件路径、具体行号，以及是否出现在 PHP 启动阶段。
会直接中断脚本的致命错误
这类错误需要优先处理，因为脚本一旦触发，执行会立即停止。
E_ERROR：运行时致命错误
E_ERROR 表示脚本在执行过程中遇到了无法继续的错误，例如调用了不存在的函数。典型日志类似：
Call to undefined function foo()这类问题通常说明代码本身有明显缺陷，或者依赖文件、扩展没有正确加载。只要它存在，脚本就不可能正常跑完。
E_CORE_ERROR：PHP 核心或扩展初始化失败
E_CORE_ERROR 说明 PHP 核心组件在初始化或运行阶段发生了致命问题，常见场景是核心扩展加载失败，例如：
Cannot load dynamic library '/usr/lib64/php/modules/imagick.so'遇到这类日志，排查重点通常不在业务代码，而在 PHP 安装和扩展配置本身，比如扩展文件是否存在、权限是否正确、模块是否与当前 PHP 版本兼容。
E_COMPILE_ERROR：编译阶段就无法通过
E_COMPILE_ERROR 多数与语法问题有关，脚本还没真正执行就已经无法编译成可运行的字节码。比如：
Parse error: syntax error, unexpected '}' in /var/www/html/test.php on line 5这说明解析器在 /var/www/html/test.php 第 5 行附近发现了不合法语法，例如缺少分号、括号不匹配或大括号闭合错误。处理方式很直接：回到对应代码位置逐行检查语法。
不会立刻停机，但不能忽视的警告
警告类问题通常不会马上终止脚本，但往往意味着结果可能不可靠，或者当前环境已经存在配置缺口。
E_WARNING：运行时非致命问题
E_WARNING 是最常见的一类。例如包含不存在的文件，或使用了未定义变量：
Warning: include(foo.php): failed to open stream: No such file or directory
Warning: Undefined variable $name脚本可能还会继续执行，但输出结果很可能已经偏离预期。对线上系统来说，这类警告不该长期堆着不管。
E_CORE_WARNING：核心组件有异常，但 PHP 仍能继续运行
E_CORE_WARNING 常见于 PHP 启动阶段，说明某些扩展加载出现问题，但还没有严重到阻止整个进程运行，例如：
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/memcache.so' ...这里的关键排查点包括扩展文件是否存在、扩展配置是否写对，以及该模块是否支持当前 PHP 版本。
E_COMPILE_WARNING：代码能跑，但兼容性已经亮黄灯
E_COMPILE_WARNING 表示编译阶段发现了潜在问题，常见情况是使用了即将弃用的旧函数。例如：
PHP Warning: Function mysql_connect() is deprecated虽然脚本当前还能工作，但像 mysql_connect 这类旧接口已经不适合作为长期方案。原文建议改用 mysqli 或 PDO，这是更稳妥的处理方向。
通知与自定义错误：脚本能跑，不代表代码没问题
通知类报错看起来“轻”，但非常适合用来提前发现逻辑漏洞和代码规范问题。
E_NOTICE：轻微异常，常常暴露真实逻辑隐患
E_NOTICE 常见于变量未初始化、数组索引不存在，或者对空值进行了不安全访问，例如：
Notice: Undefined variable: age
Notice: Trying to access array offset on value of type null这类问题通常不会让页面立刻报废，但会让代码行为变得不可预测。尤其在旧项目里，Notice 往往是后续 Warning 或 Fatal Error 的前兆。
E_USER_NOTICE / E_USER_WARNING / E_USER_ERROR：开发者主动抛出的错误
这几类错误来自应用层，通常由 trigger_error() 主动触发，用来表达业务代码中的特定状态。例如：
User Notice: Invalid input data
User Warning: Low disk space
User Error: Database connection failed它们的价值在于把原本分散的异常场景显式写进日志，便于开发者针对输入校验、资源状态或数据库连接这类问题做更细的控制。
看到 Deprecated，说明现在能跑、以后未必能跑
PHP Deprecated 表示代码使用了未来版本将移除的功能，例如旧版 MySQL 扩展或 create_function()。典型日志如下：
Deprecated: Function create_function() is deprecated这类提示不会立刻造成故障，但它直接关系到后续升级成本。如果项目后面还要迁移 PHP 版本，这一类问题越早处理越省事。
几类高频非标准报错，通常和运行资源有关
除了标准的 E_ 错误码，生产环境里还有几类非常高频的报错信息，同样值得单独关注。
Maximum execution time exceeded
这表示脚本执行时间超过了 max_execution_time 的限制，默认值通常是 30 秒。处理思路有两个：一是通过 set_time_limit() 适当延长执行时间，二是回头优化脚本逻辑，减少长时间阻塞。
Allowed memory size exhausted
这表示脚本内存消耗超过了 memory_limit，默认值通常是 128M。可以临时提高上限，但更推荐先检查是否存在一次性加载大量数据、循环中堆积变量、未及时释放结果集等问题，必要时改成分批处理。
Failed opening required file
这类报错通常出现在 require_once 或 include 找不到目标文件时。排查重点很明确：确认文件路径是否正确、文件是否存在、运行账户是否有读取权限。
实际排查时，建议按这个顺序判断
如果你在日志里同时看到多种报错，不妨按下面这个顺序处理：
- 先看是否有
E_ERROR、E_CORE_ERROR、E_COMPILE_ERROR，因为这类问题会直接让脚本停止。 - 再看是否有扩展加载失败、启动警告这类环境问题，尤其是涉及
/usr/lib64/php/modules/的日志。 - 然后处理
E_WARNING和E_NOTICE，把路径错误、未定义变量、空值访问这类隐患清掉。 - 最后整理
Deprecated提示，为后续 PHP 升级提前做兼容性准备。
PHP 日志的价值不只是“出错后补救”，更在于它能提前暴露代码质量、配置一致性和资源瓶颈。只要把错误级别和日志上下文对上号，定位问题通常会比想象中快得多。
