debug_backtrace() 在生产环境中认真使用是否安全？

Question

它的功能如此强大，以至于我担心它的稳定性和性能。

你怎么看？

更新

我正在做的是这样的：

    $old_dir = getcwd();
    chdir( dirname($included_file) );
    include ( $included_file );
    chdir( $old_dir );

基本上它只是include ( $included_file );，但在$included_file 里面找不到3.php，它与它所在的目录在同一目录中，所以我手动设置了cwd，它可以工作。但它会如果我找到它找不到的原因很好。至于为什么需要debug_backtrace，是因为3.php被另一个func包含，因为相对路径不起作用，它必须使用@987654330 @获取包含文件路径，最后使用绝对路径，如下所述。

重现起来并不容易，因为上面的代码是在方法的上下文中，还有更多..如果没有其他人遇到过这种问题，我想在这里停下来,反正成本只是多出来的3行而已，没什么大不了的。

Answer 1

debug_backtrace 在我的经验中相对昂贵，所以你应该小心它不要在循环中使用（例如，在捕获警告或通知并每次执行回溯的自定义错误处理程序中）。

对于任何类型的错误记录，我认为它都是非常宝贵的，因为它只会被调用一次，绝对不是性能问题。在错误报告中包含回溯肯定总是好的。

我不明白为什么这个函数的稳定性会有任何具体问题（即调用它会导致另一次崩溃），我从未听说过任何问题。当使用对象作为未定义 _toString 方法的函数参数时，我能看到的唯一“问题”是 this note in the User Contributed Notes。

当然，您永远不应该将回溯的结果输出给最终用户——这是不言而喻的。

Answer 2

嗯，考虑到它的名字，我不确定我是否会将它用作我的应用程序的“正常”部分——即使我不记得读过任何说它好坏的东西。

我真的不知道您所说的“严重使用”是什么意思，但是：

• 如果您的应用程序需要该功能才能运行，这可能表明您的设计存在问题
• 当您想记录错误发生的方式/位置时，此功能在错误处理程序中很有用：它会使日志文件更有用，在追踪来源时错误数

不过，不确定“错误记录”是否符合您对严重使用的定义？

Answer 3

好的，据我了解，问题如下

你有一个 php 文件，我们称它为“main.php”。在“main.php”中，您将包含某个目录中的“A.php”：

# in "main.php"
include '/some/dir/A.php';

A.php 又包含“B.php”，它与 A.php 位于同一目录中

# in "A.php"
include 'B.php'; 

问题：由于“/some/dir/”（A 和 B 所在的位置）不是“main.php”的当前版本，php 看不到来自 A.php 的 B.php

解决方案：在A.php 中使用/some/dir 的绝对完整路径。要么硬编码它，要么通过dirname(__FILE__)动态获取它

# in "A.php"
include dirname(__FILE__) .'/B.php';