PHP错误与异常处理的核心在于构建分层防御机制。首先，通过error_reporting和display_errors控制错误报告级别，开发环境开启E_ALL以便发现潜在问题，生产环境关闭display_errors防止敏感信息泄露，并启用log_errors确保错误被记录。其次，利用set_error_handler自定义错误处理器，将非致命错误（如Warning、Notice）转化为ErrorException或统一写入日志，实现灵活管理。对于可预见的逻辑异常（如文件不存在、数据库连接失败），应使用try-catch结构化处理，使业务逻辑与错误处理分离，提升代码清晰度。set_exception_handler用于捕获未被处理的异常，作为全局兜底策略，保障应用不因未捕获异常而崩溃。最后，register_shutdown_function配合error_get_last可捕获内存耗尽、解析错误等致命错误，确保极端情况下的日志留存。现代PHP实践中，推荐使用Monolog等专业日志库，集成多级处理器和格式化输出，按日志级别分流至不同目标（如文件、邮件、第三方服务），并添加时间戳、请求上下文、用户ID、调用栈等丰富信息以增强可追溯性。同时，结合Sentry等监控平台实现实时告警与错误聚合，形成完整的错误观测体系。
PHP处理错误和异常的核心，在于构建一个能够预见、捕获、记录并适当地响应程序运行时问题的机制。这包括利用PHP内置的错误报告级别、自定义错误处理函数，以及面向对象的异常处理（try-catch结构），最终目标是让应用在遇到问题时，不至于直接崩溃，而是能优雅地失败，甚至在某些情况下能够自我恢复，同时为开发者提供足够的信息去诊断和修复问题。
解决方案
在我看来，构建一个健壮的PHP应用，错误和异常处理是基石。我们不能指望代码永远不出错，能做的就是把出错的场景尽可能地掌控起来。
PHP的错误处理机制有点像一个分层防御体系。最基础的是
error_reporting()和
display_errors。
error_reporting(E_ALL)在开发环境几乎是标配，它能让你看到所有潜在的问题，哪怕是细微的通知（Notice）和警告（Warning）。而在生产环境，
display_errors则必须关闭，因为把错误信息直接暴露给用户，不仅不专业，还可能泄露敏感信息。这时候，
log_errors就显得尤为重要，它确保所有错误都被记录下来，方便我们事后排查。
更高级一点，是
set_error_handler()。这个函数允许你接管PHP的默认错误处理流程。很多时候，PHP抛出的Warning或Notice，虽然不致命，但如果置之不理，可能会导致意想不到的行为。通过自定义错误处理器，我们可以选择将这些错误转化为可捕获的
ErrorException，或者直接记录到日志，甚至在某些情况下，直接忽略掉那些我们明确知道且不影响程序运行的警告。这给了我们极大的灵活性，让我们可以把所有“非致命”错误都统一到我们自己的日志系统里。
立即学习“PHP免费学习笔记（深入）”；
而异常（Exception）处理，则是PHP提供的一种更现代、更结构化的错误处理方式，它基于面向对象的设计理念。当你遇到一个“非正常”但“可预见”的情况时，比如文件找不到、数据库连接失败、用户输入无效，就可以
throw new Exception(...)。然后，在调用这个可能抛出异常的代码块的地方，用
try-catch结构去捕获并处理它。
try块里放可能出错的代码，
catch块里定义如何应对。这个模式的好处是，它强制你思考错误发生时应该怎么办，让错误处理逻辑和业务逻辑分离，代码也因此变得更清晰。
别忘了
set_exception_handler()，这是你的最后一道防线。任何没有被
try-catch块捕获的异常，最终都会落到这里。这是一个处理“未捕获异常”的全局钩子，非常适合用来记录致命错误、向用户展示一个友好的错误页面，或者发送紧急通知给开发团队。
最后，对于那些连
set_error_handler和
set_exception_handler都无法捕获的极端情况，比如内存耗尽（Out Of Memory）或解析错误（Parse Error），
register_shutdown_function()就派上用场了。它会在脚本执行结束时被调用，无论脚本是正常结束还是因致命错误而终止。通过在其中检查
error_get_last()，我们就能捕获到那些“最致命”的错误，并将它们记录下来，这对于生产环境的稳定性至关重要。
PHP中错误和异常有什么区别？我应该什么时候用它们？
这确实是个常常让人困惑的问题。简单来说，错误（Errors）是PHP引擎本身或某些内置函数在运行时检测到的问题，它们通常表示程序在语法、运行时环境或资源方面遇到了障碍。而异常（Exceptions）则是一种更高级、更具结构化的机制，由开发者在代码中主动抛出，用于表示程序在逻辑上遇到了一个“非预期”但“可处理”的情况。
在我看来，区分它们最直观的方式是看它们的“来源”和“处理方式”。PHP的错误，比如
E_WARNING（警告，比如使用了未定义的变量）、
E_NOTICE（通知，比如访问了不存在的数组键）、
E_PARSE（解析错误，语法问题）乃至
E_ERROR（致命错误，比如调用了不存在的函数），很多时候是PHP引擎自动触发的。它们默认的处理方式是直接打印到屏幕或日志，并且根据错误级别，可能导致脚本终止。你无法直接用
try-catch去捕获一个PHP的
E_WARNING。
异常则不同，它们是程序逻辑的一部分。当你编写一个函数，比如
readFile(string $path)，如果
$path指向的文件不存在，你可以选择
throw new FileNotFoundException($path)。这个
FileNotFoundException是你自定义的，或者继承自PHP的
Exception基类。它的特点是，它必须被
try-catch块显式地捕获和处理，否则它会向上冒泡，最终被全局的
set_exception_handler捕获，导致脚本终止。
本书将PHP开发与MySQL应用相结合，分别对PHP和MySQL做了深入浅出的分析，不仅介绍PHP和MySQL的一般概念，而且对PHP和MySQL的Web应用做了较全面的阐述，并包括几个经典且实用的例子。 本书是第4版，经过了全面的更新、重写和扩展，包括PHP5.3最新改进的特性（例如，更好的错误和异常处理），MySQL的存储过程和存储引擎，Ajax技术与Web2.0以及Web应用需要注意的安全
那么，什么时候用什么呢？我的经验是：
-
对于系统级、低层次的、PHP引擎本身触发的问题，更多地通过错误处理机制来管理。 例如，
E_WARNING
或E_NOTICE
这类非致命错误，你可能希望通过set_error_handler
将它们统一记录，甚至在某些场景下，将它们提升为ErrorException
并作为异常抛出，这样就能用try-catch
来统一处理所有问题。这是一种将传统错误“现代化”处理的好方法。 - 对于应用逻辑中，可预见的、需要特定处理的“非正常”情况，果断使用异常。 比如，用户提交的数据不符合预期、调用外部API失败、数据库操作违反了完整性约束。这些情况虽然不是“正常”流程，但它们是业务逻辑的一部分，并且你希望在代码中明确地处理它们，而不是让程序默默地失败或打印一个PHP错误。异常提供了一个清晰的控制流，让你能够优雅地处理这些边缘情况。
简单来说，错误更多是“PHP告诉我代码有问题”，而异常更多是“我代码里觉得这里有问题，需要别人来处理”。现代PHP开发中，倾向于将所有可处理的问题都转化为异常来处理，这使得错误处理逻辑更加统一和可控。
如何构建一个健壮的PHP错误与异常日志系统？
构建一个健壮的日志系统，不仅仅是把错误信息打印出来那么简单，它关乎信息的完整性、可读性、可追踪性，以及在紧急情况下能否及时响应。我通常会推荐使用像Monolog这样的专业日志库，因为它提供了极大的灵活性和可扩展性。
下面是我构建日志系统的一些核心思路和实践：
选择一个强大的日志库： Monolog是PHP社区的实际标准，它支持多种处理器（Handlers），可以将日志输出到文件、数据库、Syslog、邮件甚至各种第三方服务。这玩意儿的强大之处在于，你可以根据日志级别（DEBUG, INFO, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY）把日志发送到不同的目的地。
-
集成自定义错误和异常处理器： 这是日志系统的核心。我们需要让PHP的错误和未捕获的异常都流向Monolog。
setFormatter($formatter); $logger->pushHandler($fileHandler); // 还可以添加其他处理器，比如发送邮件给管理员的Handler，但只针对CRITICAL级别 // $mailHandler = new Monolog\Handler\NativeMailerHandler( // 'admin@example.com', // 'Critical Error in App', // 'noreply@example.com', // Logger::CRITICAL // ); // $logger->pushHandler($mailHandler); // 添加一些处理器，自动为每条日志添加额外信息 $logger->pushProcessor(new WebProcessor()); $logger->pushProcessor(new MemoryUsageProcessor()); // 如果有用户登录，可以添加一个Processor来记录用户ID // $logger->pushProcessor(function ($record) { // $record['extra']['user_id'] = $_SESSION['user_id'] ?? 'guest'; // return $record; // }); // 2. 设置自定义错误处理器 set_error_handler(function ($severity, $message, $file, $line) use ($logger) { // 检查当前错误是否在error_reporting的范围内，避免重复处理 if (!(error_reporting() & $severity)) { return; } // 决定如何记录不同严重程度的错误 switch ($severity) { case E_ERROR: case E_PARSE: case E_CORE_ERROR: case E_COMPILE_ERROR: case E_USER_ERROR: $logger->error("Fatal PHP Error: " . $message, ['file' => $file, 'line' => $line, 'severity' => $severity]); // 在生产环境，这里可以考虑抛出ErrorException，让其被全局异常处理器捕获 // throw new ErrorException($message, 0, $severity, $file, $line); break; case E_WARNING: case E_USER_WARNING: $logger->warning("PHP Warning: " . $message, ['file' => $file, 'line' => $line, 'severity' => $severity]); break; case E_NOTICE: case E_USER_NOTICE: case E_DEPRECATED: case E_USER_DEPRECATED: $logger->notice("PHP Notice/Deprecated: " . $message, ['file' => $file, 'line' => $line, 'severity' => $severity]); break; default: $logger->info("PHP Info/Other Error: " . $message, ['file' => $file, 'line' => $line, 'severity' => $severity]); break; } // 返回true表示我们已经处理了错误，PHP的内部错误处理器不会再执行 return true; }); // 3. 设置自定义异常处理器 set_exception_handler(function (Throwable $exception) use ($logger) { $logger->critical("Uncaught Exception: " . $exception->getMessage(), [ 'file' => $exception->getFile(), 'line' => $exception->getLine(), 'trace' => $exception->getTraceAsString(), 'code' => $exception->getCode(), ]); // 在生产环境，这里应该向用户展示一个友好的错误页面 // header('HTTP/1.1 500 Internal Server Error'); // echo "哎呀，服务器开小差了，请稍后再试。"; // exit(1); // 终止脚本执行 }); // 4. 注册一个关闭函数，捕获致命错误（如内存溢出、解析错误） register_shutdown_function(function () use ($logger) { $error = error_get_last(); // 检查是否有致命错误发生 if ($error && in_array($error['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR])) { $logger->emergency("Shutdown Fatal Error: " . $error['message'], [ 'file' => $error['file'], 'line' => $error['line'], 'type' => $error['type'] ]); // 生产环境同样可以展示一个通用错误页面 // header('HTTP/1.1 500 Internal Server Error'); // echo "系统遭遇不可恢复的错误，请联系管理员。"; // exit(1); } }); // 示例：触发一个错误和异常 // trigger_error("这是一个测试警告", E_USER_WARNING); // throw new Exception("这是一个测试异常"); // echo $undefined_variable; // 会触发一个E_NOTICE，然后被错误处理器捕获 // parse error: eval('invalid php'); // 这类错误通常在脚本编译阶段就发生，可能不会被shutdown function完美捕获 ?> -
日志内容的丰富性： 单纯的错误信息是不够的。日志应该包含足够多的上下文信息，比如：
- 时间戳： 精确到毫秒，方便排查。
-
请求信息： URL、HTTP方法、用户IP、Referer、User-Agent等。Monolog的
WebProcessor
可以自动完成这些。 - 用户ID： 如果有登录用户，记录用户ID能快速定位问题影响范围。
- Session数据： 有时Session中的数据会导致问题。
- 调用栈（Stack Trace）： 对于异常，这是定位代码位置的关键。
- 内存使用： 有助于发现内存泄漏问题。
日志级别管理： 严格区分日志级别。
DEBUG
用于开发调试，INFO
记录正常操作流程，WARNING
表示可能的问题，ERROR
是功能受损，CRITICAL
是应用核心功能受损，ALERT
和EMERGENCY
则意味着系统崩溃或需要立即干预。在生产环境中，一般只记录WARNING
及以上级别的日志到文件，而CRITICAL
和ALERT
级别的日志可能还需要通过邮件或短信发送给管理员。日志轮转（Log Rotation）： 日志文件会越来越大，必须定期进行轮转，防止磁盘空间耗尽。可以使用Linux的
logrotate
工具，或者Monolog自带的RotatingFileHandler
。错误报告服务集成： 对于生产环境，像Sentry、Bugsnag、Raygun这类专业的错误监控服务是无价的。它们能实时聚合、去重错误，提供漂亮的UI界面，甚至能
