为什么不能在生产环境中启用Symfony调试工具？

Question

我经常发现将php错误转换为异常并注册set_error_handler和register_shutdown_function的回调非常有用，所以我决定尝试一些更可靠的解决方案，即Symfony Debug组件。然而，在introduction page中，他们警告：

您绝不能在生产环境中启用调试工具，因为它们可能向用户披露敏感信息。

启用调试组件基本上意味着调用Symfony\Component\Debug\Debug::enable()，这反过来会注册错误处理程序和异常处理程序。这也让开发人员选择$displayErrors，这意味着

是否显示错误（用于开发）或仅记录它们（用于生产）

因此，一个人可以简单地注册一些自定义日志记录器并在生产中安全使用调试器，不是吗？

我真的很想开始使用这个组件来安全地管理php中的错误情况，因为我开始重复造轮子，写了一些非常接近它的东西（当然除了质量 :D），但是那个建议不要在生产中使用它让我有点担心：你认为会出现什么问题呢？

顺便说一下，显示错误意味着这样做：$exceptionHandler = set_exception_handler('var_dump');，所以在开发期间设置$displayErrors开启应该完全没有问题，然后在生产环境中关闭它，保持所有错误都被错误处理程序捕获并记录下来的安全性。

那么如果您确实在生产中使用此组件，您会如何使用它？

- swahnee

---

我认为开发人员发出的警告是关于调试工具栏（/app_dev.php/）的，这个工具栏在生产环境中确实永远不应该被访问。它将允许任何用户显示有关您的应用程序的关键信息。 - np87

Answer 1

我认为你不应该“[使用]这个组件来安全地管理php中的错误情况”。 基本上，你得到的这些异常根本就不应该被捕获。它们意味着立即修复，并阻止开发直到修复为止。在旧时代，你可能会在同一页上收到数百个通知，因为你的错误报告级别对它们来说太低了，所以可以忽略它们。

你可以在代码中捕获的异常是所有其他异常，而不是从php错误转换而来的异常。其他任何东西都需要在开发期间尽可能修复。如果这样的错误在生产中发生，它不能减慢执行速度或显示调试信息，这就是为什么我认为它被禁用的原因。

- greg0ire

---

我理解你的观点并且大部分都同意。然而，我在考虑这种情况：假设我正在构建一个管理文件的服务，并且它期望某些文件已经就位；假设我已经完成了所有检查（文件是否存在、可读等），但是无论如何 fopen 都失败了（也许发生了一些随机故障），那么 PHP 就会抛出一个错误。在开发过程中，我无法确定这种情况不会发生，尤其是如果我正在开发一个无人值守的命令行服务，而不是传统的网站。 - swahnee

补充一下我的上一个评论，我曾经使用Filezilla部署网站时遇到过一个字符编码相关的bug，似乎是一个php文件在服务器上缺少了一个用于关闭多行注释的斜杠字符。我通过添加register_shutdown_function（这是一个简单的WordPress网站，缺少这些检查）并打印错误来追踪该bug。这绝对是一个需要错误检查机制显示漂亮的“服务器错误页面”的情况，而不是一个空白页面。 - swahnee

fopen 在出错时会返回 false，这意味着你可以处理这种情况。至于库，它们会抛出自己的异常，你可以捕获它们。例如，Symfony 的 Filesystem 组件会抛出 IOExceptions 异常。此外，并非所有错误都能被处理：“以下错误类型不能使用用户定义函数处理：E_ERROR、E_PARSE、E_CORE_ERROR、E_CORE_WARNING、E_COMPILE_ERROR、E_COMPILE_WARNING 以及大多数在调用 set_error_handler() 的文件中引发的 E_STRICT 错误。” 这意味着你应该自定义空白页面。 - greg0ire

Answer 2

我认为在生产环境中不应该调用Debug::enable()中的DebugClassLoader::enable();。

除此之外，函数的第一部分（带有错误和异常处理程序）在生产环境中应该没问题。

- Krewetka