检查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.ini设置、检查Web服务器日志，以及利用一些调试技巧和工具。没有魔法，只有一套系统性的排查流程。

解决方案

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

1. 配置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，这样连display_errors = On0和display_errors = On1都不会错过，这些小问题往往是潜在Bug的信号。生产环境可以适当降低级别，比如display_errors = On2，只记录更严重的错误。
   • 这些设置可以在php.ini文件中修改，或者通过display_errors = On4函数在脚本运行时动态调整（但display_errors和display_errors = On6在脚本执行前就生效，所以最好在php.ini中配置）。

   示例：在脚本开头临时设置

   立即学习“PHP免费学习笔记（深入）”；

   <?php ini_set('display_errors', 1); ini_set('display_startup_errors', 1); error_reporting(E_ALL); // ... 你的代码 ... ?>

2. 查看Web服务器错误日志：

   • 即使PHP配置了display_errors = On6，Web服务器（如Apache或Nginx）也有自己的错误日志。PHP的致命错误（Fatal Error），尤其是那些在PHP解析器启动前就发生的，或者资源耗尽导致的错误，可能不会被PHP自身的display_errors = On9捕获，但很可能会出现在Web服务器的On0中。
   • Apache： 通常在On1或On2。
   • Nginx： 通常在On3。
   • PHP-FPM： 如果使用PHP-FPM，它也有自己的日志，通常在On4（具体路径取决于你的FPM配置）。

3. 使用On5、On6和On7进行快速调试：

   • 这是最原始但最直接的调试方法。当我不确定某个变量的值，或者代码执行到哪里就中断了，我会在关键位置插入这些语句。
   • On8：输出变量的类型、值、长度等详细信息。
   • On9：输出数组或对象的结构和值。
   • Off0 或 Off1：强制终止脚本执行，并输出一条消息，用于确认代码是否执行到该位置。
   • 结合起来，比如：Off2，可以快速查看某个输入变量在特定点的状态。

4. 利用IDE和Xdebug：

   • 对于更复杂的项目，手动插入Off3会变得非常低效。Xdebug是一个强大的PHP调试器，可以与各种IDE（如VS Code、PhpStorm）集成。
   • 它允许你设置断点、单步执行代码、检查变量值、查看调用堆栈等。这就像给代码拍X光片一样，能清晰地看到每一步的内部状态。这是我进行深度调试的首选工具。

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

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

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

• Off4： 致命的运行时错误。脚本执行会终止。例如：调用未定义的函数。
• Off5： 运行时警告。脚本执行不会终止，但可能存在问题。例如：除数为零，文件不存在。
• Off6： 编译时解析错误。脚本在执行前就会终止。通常是语法错误。
• Off7： 运行时通知。脚本执行不会终止，通常是代码中潜在的错误或不规范用法。例如：使用未定义的变量。
• Off8 / Off9： PHP启动时发生的错误/警告。
• log_errors = On0 / log_errors = On1： PHP编译时发生的错误/警告。
• log_errors = On2 / log_errors = On3 / log_errors = On4： 用户通过log_errors = On5函数触发的错误。
• log_errors = On6： 运行时建议，用于指示代码与PHP新版本不兼容。
• log_errors = On7： 可捕获的致命错误。
• log_errors = On8 / log_errors = On9： 指示代码在未来版本中可能不再支持。
• E_ALL： 报告所有错误和警告，除了log_errors = On6。
• On2： 报告所有错误和警告，包括log_errors = On6。

如何选择和配置：

我通常的策略是：

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

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

挖错网

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

28

查看详情

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

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

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

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

解决策略：

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

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

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

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

1. Xdebug：强大的PHP调试器

   • 工作原理： Xdebug是一个PHP扩展，它允许我们通过IDE（集成开发环境）来控制PHP脚本的执行。它提供了断点、单步执行、变量检查、调用堆栈分析、性能分析等一系列高级调试功能。
   • 如何使用：
     1. 安装Xdebug： 根据你的PHP版本和操作系统安装Xdebug扩展。通常是在php.ini中添加E_ALL6（或E_ALL7）。
     2. 配置Xdebug： 在php.ini中配置Xdebug，例如设置E_ALL9，display_errors = On00或display_errors = On01和display_errors = On02。
     3. IDE集成： 大多数现代PHP IDE（如PhpStorm、VS Code with PHP Debug插件）都原生支持Xdebug。你需要在IDE中配置好监听端口，并在浏览器安装相应的Xdebug Helper插件（如Chrome的Xdebug Helper）。
     4. 设置断点： 在代码中你想要暂停执行的地方设置断点。
     5. 开始调试： 在IDE中启动调试监听，然后在浏览器中访问你的PHP页面。当代码执行到断点时，脚本会暂停，你就可以在IDE中检查变量、单步执行、查看调用堆栈了。
   • 优点： 极大地提高了调试效率，能够深入了解代码执行的每一步状态，是解决复杂Bug的利器。

2. 日志管理库 (如Monolog)：

   • 虽然PHP有内置的display_errors = On9，但它相对简单。在大型应用中，我们通常使用专业的日志管理库，比如Monolog。
   • 功能： Monolog可以让你将日志输出到各种目标（文件、数据库、Slack、邮件等），并支持不同的日志级别（DEBUG, INFO, WARNING, ERROR, CRITICAL等）。它还允许你添加上下文信息，使日志更具可读性和可追溯性。
   • 用途： 除了错误，你还可以记录应用程序的运行时状态、用户行为等，这对于在生产环境中追踪问题和分析性能非常有帮助。

3. 性能分析工具 (Profiler)：

   • 当你的PHP应用运行缓慢，但没有明显错误时，性能分析工具就派上用场了。Xdebug本身也提供了简单的Profiler功能，但更专业的工具有：
     • Blackfire.io： 一个商业级的性能分析工具，可以提供非常详细的函数调用图和性能瓶颈分析。
     • Tideways： 类似于Blackfire，也提供深入的性能监控和分析。
   • 用途： 它们能告诉你每个函数执行了多长时间、占用了多少内存，从而帮助你定位性能瓶颈并进行优化。

4. 单元测试与集成测试：

   • 这严格来说不是“调试”方法，但却是预防和发现Bug的极其高效的手段。通过编写自动化测试，你可以在代码部署前就发现问题。
   • PHPUnit： 是PHP中最流行的单元测试框架。
   • 用途： 每次代码修改后运行测试，如果测试失败，就能立即定位到问题所在。这大大减少了手动调试的时间和精力。

结合这些方法，我们可以构建一个从开发到生产，从错误报告到性能分析的完整调试和监控体系，让PHP开发变得更加高效和可靠。