PHP 报错信息怎么看？开发阶段应该如何打开和关闭错误显示

PHP程序出现报错时，错误信息往往是开发者判断问题所在的第一条线索。一个完整的错误提示通常会告诉你发生了什么问题、涉及哪个文件以及大致位于哪一行，因此正确理解错误信息，比单纯看到页面空白后不断修改代码更加有效。PHP的错误显示和错误记录由多个配置共同控制，开发环境和正式网站的处理方式也应该有所区别。

在本地开发或者测试网站时，通常应该尽可能让PHP显示完整的错误信息。这样做的目的不是让页面看起来更复杂，而是让开发者能够及时发现变量未定义、函数调用错误、文件加载失败以及其他代码问题。PHP官方文档也建议开发环境使用E_ALL，以便开发者看到PHP报告的各种问题；而在生产环境中，则应关闭直接向访问者显示错误的功能。

控制PHP错误显示最常见的配置是display_errors。这个配置决定PHP产生的错误是否直接作为网页输出的一部分显示出来，如果设置为On，符合条件的错误可能直接出现在浏览器页面中，如果设置为Off，则不会直接显示给访问者。需要注意的是，display_errors只是控制错误是否显示，并不等于错误是否发生，也不等于错误是否被记录到日志中。

开发环境中通常可以使用下面这样的配置：

error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');

其中error_reporting决定PHP需要报告哪些级别的问题，E_ALL表示报告全部错误级别。display_errors负责把错误显示出来，而display_startup_errors主要涉及PHP启动阶段产生的问题。PHP官方文档指出，某些错误发生在脚本真正执行之前，因此单纯在PHP代码中使用ini_set并不一定能够显示这些错误。

如果网站出现空白页面，开发者经常会在入口文件最前面临时加入这几行配置。这种方法对于快速定位问题非常实用，但它更适合作为开发和排查故障的临时措施，而不应该长期保留在正式网站上。尤其是网站已经部署到互联网以后，如果错误信息直接输出到页面，错误提示中可能包含服务器路径、数据库连接信息、文件位置以及其他不应该公开的数据。

生产环境最重要的原则，是不要让普通访问者直接看到PHP内部错误。PHP官方文档明确建议生产网站关闭display_errors，同时使用错误日志记录问题。这样既可以避免敏感信息暴露，也不会因为关闭页面显示而完全失去故障排查能力。

与display_errors配合使用的另一个重要配置是log_errors。它决定PHP产生的错误是否写入服务器错误日志，而error_log可以指定日志记录的位置。生产网站通常应该关闭页面上的错误显示，同时开启错误日志，这样用户看到的是正常的错误页面，而开发者或者服务器管理员仍然可以从日志中找到具体原因。

例如，生产环境可以采用类似下面的配置：

error_reporting(E_ALL);
ini_set('display_errors', '0');
ini_set('log_errors', '1');

这里需要特别区分error_reporting和display_errors。前者决定报告哪些问题，后者决定这些问题是否直接显示给用户，两者并不是同一个功能。生产环境并不意味着必须完全停止错误报告，更合理的做法通常是继续记录重要错误，同时避免把内部信息直接输出到网页。

PHP错误信息本身也有一定的阅读规律。常见提示通常会包含错误类型、具体描述、文件路径和行号，例如Undefined variable、Undefined array key、Call to undefined function或者Failed opening required等信息。看到错误以后，不应该只看最前面的错误名称，还应该结合文件名、行号以及产生错误的代码上下文判断问题究竟来自哪里。

例如Undefined array key通常意味着程序尝试读取一个不存在的数组键。造成这种情况的原因可能是表单没有提交对应字段，也可能是URL参数不存在，或者数据库查询结果与程序原本预期的数据结构不同。因此，不能看到一个错误就立即给出固定答案，而应该检查变量来自哪里、数据是否真的存在以及代码是否正确处理了缺失情况。

PHP不同版本对错误的处理方式也可能有所变化。过去某些问题可能只是Notice或者较轻的提示，而新版本可能会以更明显的Warning等形式出现，因此升级PHP以后突然出现大量错误，并不一定意味着服务器坏了，也可能是旧代码与新版本行为之间出现了兼容性问题。开发者应该根据具体错误信息检查代码，而不是简单地把所有提示关闭。

有些开发者遇到警告以后，会使用@符号把错误隐藏掉。虽然PHP确实提供错误控制运算符，但长期依赖这种方式并不能解决真正的问题，反而可能让开发者失去重要的调试信息。对于正式项目，更好的方式是找到产生警告的原因并修正代码，而不是让错误从页面和日志中消失。

服务器配置也是PHP错误处理中的一个重要环节。PHP可以通过php.ini以及其他允许修改配置的方式控制错误报告，具体能够在哪里修改，取决于服务器运行方式和配置权限。Apache环境下某些PHP配置可以通过服务器配置或者本地.htaccess进行调整，但不同PHP运行方式支持的配置项目并不完全相同，因此不能把一种服务器环境的配置方法直接套用到另一台服务器。

对于使用Nginx和PHP-FPM的网站，PHP通常不是由Nginx直接执行，而是通过FastCGI交给PHP-FPM处理。因此排查错误时，需要同时考虑Nginx日志、PHP-FPM日志以及PHP自身的错误日志。遇到500错误或者页面突然变成空白时，只修改网页代码并不一定能够找到问题，服务器日志往往能够提供更直接的线索。

如果网站使用WordPress或者其他PHP框架，还需要考虑框架自己的错误处理机制。有些框架会接管PHP错误并生成自己的错误页面，有些系统则会把异常写入独立日志。因此，如果php.ini已经开启错误显示，但浏览器仍然没有出现预期的错误信息，就应该检查框架或者应用程序自己的配置。

开发者还应该注意一个常见问题，那就是修改php.ini以后并不一定马上生效。PHP运行方式、PHP-FPM、Apache以及主机环境不同，配置文件的读取方式也可能不同。有时候修改的是一个php.ini文件，而实际运行网站的PHP使用的是另一个配置文件，因此排查配置问题时，可以通过phpinfo或者其他方式确认当前PHP实际加载的配置。

如果网站已经上线，比较稳妥的做法是让用户看到简洁的错误页面，同时把详细信息写入服务器日志。这样既能够避免文件路径、数据库信息和内部代码结构暴露给外部访问者，又可以让开发者在出现故障时通过日志定位问题。PHP官方文档同样建议生产环境使用错误日志，而不是直接向用户显示错误。

对于开发者来说，最实用的原则其实很简单。开发阶段应该尽可能打开E_ALL并显示错误，让问题尽早暴露出来；网站正式运行以后，则应该关闭display_errors，同时开启log_errors并妥善保存日志。这样处理，既方便开发和维护，也能够避免PHP错误信息直接暴露给网站访问者。

如果只是自己开发的网站，最容易记住的一套思路就是开发时看屏幕，生产时看日志。错误信息不是需要害怕的东西，而是PHP告诉开发者程序哪里出了问题的一种机制。真正需要避免的并不是错误本身，而是发现错误以后选择隐藏它，而没有找到产生错误的原因。