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