我很确定我不仅仅是一个注意到 PHP 上的简单解析错误的人，如果存在于非常嵌套的场景中（例如，一个引用另一个对象实例的对象实例，该对象实例引用另一个具有非常小的解析错误的对象实例，所有这些都是自动加载的）可以使 PHP 永远挂起，而不是像通常那样报告解析错误并停止执行——我已经看到很多次了，而且在非常不同的代码库中，总是使用正确的 error_reporting 设置集.
有什么办法吗？即，是否可以强制以某种方式显示解析错误报告？
作为记录，我 100% 确定这些挂起是由于 PHP 没有正确处理解析错误造成的，因为我已经多次调试过这种行为；我问的原因是因为当这些挂起发生时，基本上是一无所知，甚至无法判断 PHP 是否表现得好笑，或者代码中的某个地方确实存在故障循环——这需要时间来调试，时间可能如果您知道，PHP 报告了应有的解析错误，则可以保存。
正如评论中部分提到的，error_reporting(E_ALL)可以帮助显示所有错误。您可能还必须使用ini_set并使其display_errors具有on.
就个人而言，我认为您的问题不是很清楚，您应该改进格式并使其更易于理解。
更新：您运行代码的服务器/计算机似乎很慢。不应该真正发生“闲逛”。或者你能更详细地描述它吗？
此外，您可能会陷入无限或接近无限的循环。仔细检查您的代码，因为除非您发布所有代码，否则这是我们可以帮助您的限制。
更新 2：似乎您在尝试调用对象时可能输入了错误的对象名称。否则，可能是您没有正确声明您的对象。
很可能是其中之一。
原来罪魁祸首是xdebug.collect_params，文档非常正确地建议保持禁用状态。某些错误只是在调用堆栈跟踪的参数中生成大量数据，这些数据耗尽了 xdebug 并将 collect_params 设置为 4 并使 xdebug 和扩展 PHP 挂起，即使我有一个自定义异常处理程序，但实际上从未从 xdebug 检索堆栈跟踪，但显然 xdebug 无论如何都会收集这些数据。
这很难调试，因为：a) 复制并不简单 b) 使用 xdebug 进行分析没有帮助 c) 使用 xdebug + dbgp 单步执行代码也无济于事 d) 几乎没有留下任何痕迹（没有双关语）除了偶尔将错误记录到 php error_log 文件和 e) 使用自定义异常处理程序之外，怀疑 xdebug 并不明显，因为我没有在处理异常的过程中涉及它，或者我认为。
所以没有死亡的解析错误这样的事情，我学会了永远不要认为这不是我的错 :) 希望这个答案至少能在未来帮助其他人。