怎么检查php报错_php错误调试与报错信息查看方法-php教程-PHP中文网

检查PHP报错需配置错误报告、查看日志并使用调试工具。首先设置php.ini中display_errors=On（开发环境）、log_errors=On，并指定error_log路径；生产环境关闭display_errors，调整error_reporting级别如E_ALL & ~E_NOTICE。当页面空白时，检查是否因display_errors关闭导致错误不可见，查看Web服务器（Apache/Nginx）及PHP-FPM错误日志，确认是否存在致命错误或内存耗尽问题。使用var_dump()、print_r()和die()进行简单调试，结合Xdebug实现断点调试与变量追踪。推荐使用Monolog记录多目标日志，Blackfire或Tideways分析性能瓶颈，通过PHPUnit编写单元测试预防Bug。综合配置、日志、工具与测试构建完整调试体系。

怎么检查php报错_php错误调试与报错信息查看方法

检查PHP报错，核心在于配置PHP环境使其能够报告错误，并知道去哪里查看这些报告。这通常涉及调整php.ini设置、检查Web服务器日志，以及利用一些调试技巧和工具。没有魔法，只有一套系统性的排查流程。

解决方案

要有效地检查PHP错误并进行调试，我通常会从以下几个方面入手：

配置PHP错误报告： 这是基础中的基础。
- display_errors = On (开发环境)： 这个设置控制PHP错误是否直接输出到浏览器。在开发阶段，我总是把它设为On，这样错误能一目了然。但切记生产环境要设为Off，避免敏感信息泄露。
- log_errors = On (所有环境)： 无论开发还是生产，这个都应该On。它确保PHP错误被写入日志文件，即使display_errors关闭，我们也能追踪问题。
- error_log = /path/to/php_errors.log： 指定错误日志文件的路径。确保PHP进程对这个路径有写入权限。
- error_reporting = E_ALL (开发环境)： 这是错误报告的级别。在开发时，我倾向于设置为E_ALL，这样连Notice和Warning都不会错过，这些小问题往往是潜在Bug的信号。生产环境可以适当降低级别，比如E_ALL & ~E_NOTICE & ~E_DEPRECATED，只记录更严重的错误。
- 这些设置可以在php.ini文件中修改，或者通过ini_set()函数在脚本运行时动态调整（但display_errors和log_errors在脚本执行前就生效，所以最好在php.ini中配置）。
示例：在脚本开头临时设置

立即学习“PHP免费学习笔记（深入）”；
```
<?php
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
// ... 你的代码 ...
?>
```
登录后复制
查看Web服务器错误日志：
- 即使PHP配置了log_errors，Web服务器（如Apache或Nginx）也有自己的错误日志。PHP的致命错误（Fatal Error），尤其是那些在PHP解析器启动前就发生的，或者资源耗尽导致的错误，可能不会被PHP自身的error_log捕获，但很可能会出现在Web服务器的error.log中。
- Apache： 通常在/var/log/apache2/error.log或/var/log/httpd/error.log。
- Nginx： 通常在/var/log/nginx/error.log。
- PHP-FPM： 如果使用PHP-FPM，它也有自己的日志，通常在/var/log/php-fpm/www-error.log（具体路径取决于你的FPM配置）。
使用var_dump()、print_r()和die()进行快速调试：
- 这是最原始但最直接的调试方法。当我不确定某个变量的值，或者代码执行到哪里就中断了，我会在关键位置插入这些语句。
- var_dump($variable);：输出变量的类型、值、长度等详细信息。
- print_r($array_or_object);：输出数组或对象的结构和值。
- die('Debug point reached!'); 或 exit('Script terminated here.');：强制终止脚本执行，并输出一条消息，用于确认代码是否执行到该位置。
- 结合起来，比如：var_dump($user_input); die();，可以快速查看某个输入变量在特定点的状态。
利用IDE和Xdebug：
- 对于更复杂的项目，手动插入var_dump会变得非常低效。Xdebug是一个强大的PHP调试器，可以与各种IDE（如VS Code、PhpStorm）集成。
- 它允许你设置断点、单步执行代码、检查变量值、查看调用堆栈等。这就像给代码拍X光片一样，能清晰地看到每一步的内部状态。这是我进行深度调试的首选工具。

PHP错误报告级别有哪些，我该如何选择和配置？

PHP的错误报告级别是一组常量，用于指定哪些类型的错误应该被报告。理解这些级别对于有效调试至关重要。

主要的错误报告级别包括：

E_ERROR： 致命的运行时错误。脚本执行会终止。例如：调用未定义的函数。
E_WARNING： 运行时警告。脚本执行不会终止，但可能存在问题。例如：除数为零，文件不存在。
E_PARSE： 编译时解析错误。脚本在执行前就会终止。通常是语法错误。
E_NOTICE： 运行时通知。脚本执行不会终止，通常是代码中潜在的错误或不规范用法。例如：使用未定义的变量。
E_CORE_ERROR / E_CORE_WARNING： PHP启动时发生的错误/警告。
E_COMPILE_ERROR / E_COMPILE_WARNING： PHP编译时发生的错误/警告。
E_USER_ERROR / E_USER_WARNING / E_USER_NOTICE： 用户通过trigger_error()函数触发的错误。
E_STRICT： 运行时建议，用于指示代码与PHP新版本不兼容。
E_RECOVERABLE_ERROR： 可捕获的致命错误。
E_DEPRECATED / E_USER_DEPRECATED： 指示代码在未来版本中可能不再支持。
E_ALL： 报告所有错误和警告，除了E_STRICT。
E_ALL | E_STRICT： 报告所有错误和警告，包括E_STRICT。

如何选择和配置：

我通常的策略是：

挖错网

一款支持文本、图片、视频纠错和AIGC检测的内容审核校对平台。

查看详情

开发环境： 始终配置error_reporting = E_ALL。我甚至会加上E_STRICT和E_DEPRECATED，确保所有潜在问题都能被发现。这样能尽早发现代码中的隐患，避免它们在生产环境爆炸。
- 在php.ini中：error_reporting = E_ALL
- 在脚本中：ini_set('error_reporting', E_ALL);
生产环境： 我会选择性地报告错误，通常是只报告致命错误、警告和解析错误，而忽略通知和弃用警告，因为这些在生产环境中可能过于“嘈杂”，会填充日志文件，掩盖真正的问题。同时，绝不能在生产环境开启display_errors。
- 在php.ini中：error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
- 在脚本中：ini_set('error_reporting', E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED);

通过位运算符（& 和 ~），我们可以精确地组合或排除特定的错误类型。比如~E_NOTICE表示“排除通知”。

为什么我的PHP页面一片空白，没有任何错误提示？

这种情况，我称之为“白屏死机”（White Screen of Death），是PHP开发中最令人头疼的场景之一。页面一片空白，没有任何错误信息，这通常意味着PHP代码发生了致命错误 (Fatal Error)，并且错误报告配置不当，导致错误信息被隐藏了。

造成这种现象的原因通常有：

display_errors = Off： 这是最常见的原因。在生产环境中，出于安全考虑，display_errors通常会被设置为Off，这意味着PHP错误不会直接输出到浏览器。如果开发环境也沿用了这个设置，那么一旦出现致命错误，页面就会一片空白。
致命错误在PHP解析器启动前发生： 有些错误，比如php.ini配置错误，或者在非常早期的代码加载阶段就出现了致命错误，PHP可能根本来不及执行display_errors或error_log的设置，就直接终止了。
内存耗尽 (Memory Exhausted)： PHP脚本尝试分配超出其memory_limit的内存时，会触发一个致命错误。这种错误有时也不会在浏览器中显示，而是直接导致白屏。
Web服务器或PHP-FPM的错误： 有时问题不在PHP脚本本身，而是Web服务器（Apache/Nginx）或PHP-FPM在处理请求时出现问题。例如，PHP-FPM进程崩溃，或者与Web服务器的通信中断。

解决策略：

面对白屏，我的排查步骤是：

检查php.ini：
- 临时开启display_errors = On： 在开发环境中，这是最快的解决方法。找到你的php.ini文件，把display_errors设为On，并确保error_reporting设置为E_ALL。修改后记得重启Web服务器或PHP-FPM。
- 确保log_errors = On并检查error_log路径： 即使display_errors是Off，错误也应该被记录到日志文件。确认log_errors为On，并且error_log指向一个有效且有写入权限的路径。
查看Web服务器错误日志：
- 这是白屏时最重要的线索来源。无论是Apache的error.log、Nginx的error.log还是PHP-FPM的www-error.log，它们往往能捕获到PHP自身无法报告的致命错误信息。
逐步注释代码或使用die()：
- 如果日志没有提供明确线索，我会采用二分法。从脚本的顶部开始，逐步注释掉代码块，或者在代码的关键位置插入die('Checkpoint X');。通过观察哪个die()没有被执行，可以大致定位到出错的代码区域。
检查文件权限和路径：
- 有时是文件不存在、包含文件路径错误，或者PHP进程没有读取或写入某些文件的权限，这也会导致致命错误。

除了PHP自带的错误报告，还有哪些更高效、更现代的PHP调试方法？

仅仅依赖PHP自带的错误报告和var_dump在现代PHP开发中是远远不够的。为了更高效、更深入地调试，我们通常会借助更专业的工具和方法。

Xdebug：强大的PHP调试器
- 工作原理： Xdebug是一个PHP扩展，它允许我们通过IDE（集成开发环境）来控制PHP脚本的执行。它提供了断点、单步执行、变量检查、调用堆栈分析、性能分析等一系列高级调试功能。
- 如何使用：
  1. 安装Xdebug： 根据你的PHP版本和操作系统安装Xdebug扩展。通常是在php.ini中添加zend_extension=xdebug.so（或.dll）。
  2. 配置Xdebug： 在php.ini中配置Xdebug，例如设置xdebug.mode=debug，xdebug.start_with_request=yes或xdebug.client_host和xdebug.client_port。
  3. IDE集成： 大多数现代PHP IDE（如PhpStorm、VS Code with PHP Debug插件）都原生支持Xdebug。你需要在IDE中配置好监听端口，并在浏览器安装相应的Xdebug Helper插件（如Chrome的Xdebug Helper）。
  4. 设置断点： 在代码中你想要暂停执行的地方设置断点。
  5. 开始调试： 在IDE中启动调试监听，然后在浏览器中访问你的PHP页面。当代码执行到断点时，脚本会暂停，你就可以在IDE中检查变量、单步执行、查看调用堆栈了。
- 优点： 极大地提高了调试效率，能够深入了解代码执行的每一步状态，是解决复杂Bug的利器。
日志管理库 (如Monolog)：
- 虽然PHP有内置的error_log，但它相对简单。在大型应用中，我们通常使用专业的日志管理库，比如Monolog。
- 功能： Monolog可以让你将日志输出到各种目标（文件、数据库、Slack、邮件等），并支持不同的日志级别（DEBUG, INFO, WARNING, ERROR, CRITICAL等）。它还允许你添加上下文信息，使日志更具可读性和可追溯性。
- 用途： 除了错误，你还可以记录应用程序的运行时状态、用户行为等，这对于在生产环境中追踪问题和分析性能非常有帮助。
性能分析工具 (Profiler)：
- 当你的PHP应用运行缓慢，但没有明显错误时，性能分析工具就派上用场了。Xdebug本身也提供了简单的Profiler功能，但更专业的工具有：
  - Blackfire.io： 一个商业级的性能分析工具，可以提供非常详细的函数调用图和性能瓶颈分析。
  - Tideways： 类似于Blackfire，也提供深入的性能监控和分析。
- 用途： 它们能告诉你每个函数执行了多长时间、占用了多少内存，从而帮助你定位性能瓶颈并进行优化。
单元测试与集成测试：
- 这严格来说不是“调试”方法，但却是预防和发现Bug的极其高效的手段。通过编写自动化测试，你可以在代码部署前就发现问题。
- PHPUnit： 是PHP中最流行的单元测试框架。
- 用途： 每次代码修改后运行测试，如果测试失败，就能立即定位到问题所在。这大大减少了手动调试的时间和精力。