我正在运行带有 PHP 5.3.2 的 Apache 2.2.15，“display_errors”被禁用，“display_startup_errors”被禁用，“log_errors”被启用。
在我的设置中(所以我认为这是一种规范)，PHP 会在出现 fatal error 时中止，这很好，并且将 HTTP 状态代码设置为 500。 fatal error 包括 E_ERROR、E_PARSE、E_CORE_ERROR、E_COMPILE_ERROR、E_USER_ERROR 和可能的 E_RECOVERABLE_ERROR(我自己无法触发它，因此无法轻易检查发生了什么)。我认为将代码设置为 500 是一个好主意，因为我认为这是正确的做法 - 显然，如果您的脚本包含语法错误和/或未能执行在运行时应该执行的操作，那么它是服务器错误，如果我们将 PHP 视为服务器的一部分。
现在，这是重要的部分:
无论如何，我现在已经安装了 XDebug 以更好地跟踪错误，但我现在可以看到，无论错误如何，即使脚本像以前一样因 fatal error 而中止，HTTP 状态代码始终为 200。这打破了我的客户端，它通过 HTTP 与 Apache/PHP 进行“对话”:|
此外，将 display_errors 设置为 On/1，使 PHP 不再将 HTTP 状态代码设置为 500，并表现出与上述 XDebug 完全相同的行为。
我在这里非常依赖可靠的状态代码行为，这一切让我相信这是某种侥幸或随机的天气......或者我错过了什么？
更新
有一篇博文概括了这个问题: http://talideon.com/weblog/2008/02/php-errors.cfm
就我而言，我已禁用 XDebug，因为它首先导致了不良行为。无论如何，我只将它用于堆栈跟踪，现在为此使用自定义错误处理程序。此外，链接的文章来自 2008 年，显然 PHP 这些天确实将 HTTP 状态代码自动设置为 500。它在这里这样做。当然，没有 XDebug。
最佳答案
我假设您正在使用自定义错误处理程序来发出 500。
我不太了解 XDebug，但根据 this article ，它会注册自己的错误处理程序，可能会在此过程中覆盖您的错误处理程序:
Please note that the extended error display of xdebug does not work if you define a custom error handler using register_error_handler(). This is because xdebug internally uses the same mechanism. Should your scripts use a custom error handler, you can still use the function xdebug_get_function_stack() to output the stack trace in your custom error handler.
但是，对于生产用途，无论如何您都不会激活 XDebug，是吗？
至于为什么激活display_errors()时输出200，我不明白。您可以发布您的自定义错误处理函数以供查看吗？
关于php - 如何让 PHP 在出现任何错误情况时自动将 HTTP 状态代码设置为 500？ (包括用户无法处理的)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3075174/