PHP debug_backtrace的胡思亂想
- 黄舟原創
- 2016-12-28 13:33:221309瀏覽
簡述
可能大家都知道，php中有一個函數叫debug_backtrace，它可以回溯追蹤函數的呼叫訊息，可以說是一個調試利器。
好，來複習一下。
one();
function one() {
two();
}
function two() {
three();
}
function three() {
print_r( debug_backtrace() );
}
/*
输出：
Array
(
[0] => Array
(
[file] => D:\apmserv\www\htdocs\test\debug\index.php
[line] => 10
[function] => three
[args] => Array
(
)
)
[1] => Array
(
[file] => D:\apmserv\www\htdocs\test\debug\index.php
[line] => 6
[function] => two
[args] => Array
(
)
)
[2] => Array
(
[file] => D:\apmserv\www\htdocs\test\debug\index.php
[line] => 3
[function] => one
[args] => Array
(
)
)
)
*/順便提一下類似的函數：debug_print_backtrace，與之不同的是它會直接印出回溯訊息。
回來看debug_backtrace，從名字來看用途很明確，是讓開發者用來調試的。直到有一天我注意到它回傳的file參數，file表示函數或方法的呼叫腳本來源（在哪個腳本檔案使用的）。忽然我想到，如果目前腳本知道呼叫來源，那是否可以根據這個來源的不同，來實現一些有趣的功能，例如檔案權限管理、動態載入等。
實戰
實現魔術函數
獲取當前函數或方法的名稱
儘管PHP中已經有了__FUNCTION__和__METHOD__bug名稱的方法。
程式碼如下：
//函数外部输出getFuncName的值
echo getFuncName();
printFuncName();
Object::printMethodName();
//调用了上面两个函数后，再次在外部输出getFuncName，看看是否有‘缓存’之类的问题
echo getFuncName();
function printFuncName() {
echo getFuncName();
}
class Object {
static function printMethodName() {
echo getFuncName();
}
}
/**
* 获取当前函数或者方法的名称
* 函数名叫getFuncName，好吧，其实method也可以当做function，实在想不出好名字
*
* @return string name
*/
function getFuncName() {
$debug_backtrace = debug_backtrace();
//如果函数名是以下几个，表示载入了脚本，并在函数外部调用了getFuncName
//这种情况应该返回空
$ignore = array(
'include',
'include_once',
'require',
'require_once'
);
//第一个backtrace就是当前函数getFuncName，再上一个（第二个）backtrace就是调用getFuncName的函数了
$handle_func = $debug_backtrace[1];
if( isset( $handle_func['function'] ) && !in_array( $handle_func['function'], $ignore ) ) {
return $handle_func['function'];
}
return null;
}
//输出：
//null
//printFuncName
//printMethodName
//null看起來沒有問題，很好。
加載相對路徑文件
如果在專案中要載入相對路徑的文件，必需使用include或require之類的原生方法，但現在有了debug_backtrace，我可以使用自訂函數來載入相對路徑文件。
新建一個項目，目錄結構如下：
我想在index.php中呼叫自訂函數，並使用相對路徑去載入package/package.php，並且在package.php中使用同樣的方法載入_inc_func.php
三個檔案的程式碼如下（留意index.php和package.php呼叫import函數的程式碼）：
index.php：
<?php
import( './package/package.php' );
/**
* 加载当前项目下的文件
*
* @param string $path 相对文件路径
*/
function import( $path ) {
//获得backstrace列表
$debug_backtrace = debug_backtrace();
//第一个backstrace就是调用import的来源脚本
$source = $debug_backtrace[0];
//得到调用源的目录路径，和文件路径结合，就可以算出完整路径
$source_dir = dirname( $source['file'] );
require realpath( $source_dir . '/' . $path );
}
?>package.php：
<?php echo 'package'; import( './_inc_func.php' ); ?>
_inc_func.
<?phpecho '_inc_func';?>
運行index.php：
//输出： //package //_inc_func
可以看到，我成功了。
思考：這個方法我覺得非常強大，除了相對路徑之外，可以根據這個思路引伸出相對包、相對模組之類的抽象特性，對於一些項目來說可以增強模組化的作用。
管理文件調用權限
我約定一個規範：文件名前帶下劃線的只能被當前目錄的文件調用，也就是說這種文件屬於當前目錄'私有'，其它目錄的文件不允許載入它們。
這樣做的目的很明確：為了降低程式碼耦合性。在專案中，很多時候有些文件只用在特定的腳本中。但是經常發生的事情是：一些程式設計師發現這些腳本有自己需要用到的函數或類，因此直接載入它來達到自己的目的。這樣的做法很不好，原本這些腳本編寫的目的僅僅為了輔助某些介面實現，它們並沒有考慮到其它通用性。萬一介面內部需要重構，同樣需要改動這些特定的腳本文件，但是改動後一些看似與這個接口無關腳本卻突然無法運行了。一經檢查，卻發現文件的引用錯綜複雜。
規範只是監督作用，不排除有人為了一己私慾而違反這個規範，或者無意中違反了。最好的方法是落實到程式碼中，讓程式自動去偵測這種情況。
那么对于这个项目来说，_inc_func.php属于package目录的私有文件，只有package.php可以载入它，而index.php则没有这个权限。
package目录是一个包，package.php下提供了这个包的接口，同时_inc_func.php有package.php需要用到的一些函数。index.php将会使用这个包的接口文件，也就是package.php
它们的代码如下
index.php：
<?php
header("Content-type: text/html; charset=utf-8");
//定义项目根目录
define( 'APP_PATH', dirname( __FILE__ ) );
import( APP_PATH . '/package/package.php' );
//输出包的信息
Package_printInfo();
/**
* 加载当前项目下的文件
*
* @param string $path 文件路径
*/
function import( $path ) {
//应该检查路径的合法性
$real_path = realpath( $path );
$in_app = ( stripos( $real_path, APP_PATH ) === 0 );
if( empty( $real_path ) || !$in_app ) {
throw new Exception( '文件路径不存在或不被允许' );
}
include $real_path;
}
?>_inc_func.php：
<?php
function _Package_PrintStr( $string ) {
echo $string;
}
?>package.php：
<?php
define( 'PACKAGE_PATH', dirname( __FILE__ ) );
//引入私有文件
import( PACKAGE_PATH . '/_inc_func.php' );
function Package_printInfo() {
_Package_PrintStr( '我是一个包。' );
}
?>运行index.php：
//输出： //我是一个包。
整个项目使用了import函数载入文件，并且代码看起来是正常的。但是我可以在index.php中载入package/_inc_func.php文件，并调用它的方法。
index.php中更改import( APP_PATH . '/package/package.php' );处的代码，并运行：
import( APP_PATH . '/package/_inc_func.php' ); _Package_PrintStr( '我载入了/package/_inc_func.php脚本' ); //输出： //我载入了/package/_inc_func.php脚本
那么，这时可以使用debug_backtrace检查载入_inc_func.php文件的路径来自哪里，我改动了index.php中的import函数，完整代码如下：
/**
* 加载当前项目下的文件
*
* @param string $path 文件路径
*/
function import( $path ) {
//首先应该检查路径的合法性
$real_path = realpath( $path );
$in_app = ( stripos( $real_path, APP_PATH ) === 0 );
if( empty( $real_path ) || !$in_app ) {
throw new Exception( '文件路径不存在或不被允许' );
}
$path_info = pathinfo( $real_path );
//判断文件是否属于私有
$is_private = ( substr( $path_info['basename'], 0, 1 ) === '_' );
if( $is_private ) {
//获得backstrace列表
$debug_backtrace = debug_backtrace();
//第一个backstrace就是调用import的来源脚本
$source = $debug_backtrace[0];
//得到调用源路径，用它来和目标路径进行比较
$source_dir = dirname( $source['file'] );
$target_dir = $path_info['dirname'];
//不在同一目录下时抛出异常
if( $source_dir !== $target_dir ) {
$relative_source_file = str_replace( APP_PATH, '', $source['file'] );
$relative_target_file = str_replace( APP_PATH, '', $real_path );
$error = $relative_target_file . '文件属于私有文件,' . $relative_source_file . '不能载入它。';
throw new Exception( $error );
}
}
include $real_path;
}这时再运行index.php，将产生一个致命错误：
//输出： //致命错误：/package/_inc_func.php文件属于私有文件,/index.php不能载入它
而载入package.php则没有问题，这里不进行演示。
可以看到，我当初的想法成功了。尽管这样，在载入package.php后，其实在index.php中仍然还可以调用_inc_func.php的函数（package.php载入了它）。因为除了匿名函数，其它函数是全局可见的，包括类。不过这样或多或少可以让程序员警觉起来。关键还是看程序员本身，再好的规范和约束也抵挡不住烂程序员，他们总是会比你‘聪明’。
debug_backtrace的'BUG'
如果使用call_user_func或者call_user_func_array调用其它函数，它们调用的函数里面使用debug_backtrace，将获取不到路径的信息。
例：
call_user_func('import');
function import() {
print_r( debug_backtrace() );
}
/*
输出：
Array
(
[0] => Array
(
[function] => import
[args] => Array
(
)
)
[1] => Array
(
[file] => F:\www\test\test\index.php
[line] => 3
[function] => call_user_func
[args] => Array
(
[0] => import
)
)
)
*/注意输出的第一个backtrace，它的调用源路径file没有了，这样一来我之前的几个例子将会产生问题。当然可能你注意到第二个backtrace，如果第一个没有就往回找。但经过实践是不可行的，之前我就碰到这种情况，同样会有问题，但是现在无法找回那时的代码了，如果你发现，请将问题告诉我。就目前来说，最好不要使用这种方法，我有一个更好的解决办法，就是使用PHP的反射API。
使用反射
使用反射API可以知道函数很详细的信息，当然包括它声明的文件和所处行数
call_user_func('import');
function import() {
$debug_backtrace = debug_backtrace();
$backtrace = $debug_backtrace[0];
if( !isset( $backtrace['file'] ) ) {
//使用反射API获取函数声明的文件和行数
$reflection_function = new ReflectionFunction( $backtrace['function'] );
$backtrace['file'] = $reflection_function->getFileName();
$backtrace['line'] = $reflection_function->getStartLine();
}
print_r($backtrace);
}
/*
输出：
Array
(
[function] => import
[args] => Array
(
)
[file] => F:\www\test\test\index.php
[line] => 5
)
*/可以看到通过使用反射接口ReflectionMethod的方法，file又回来了。
类方法的反射接口是ReflectionMethod，获取声明方法同样是getFileName。
总结
在一个项目中，我通常不会直接使用include或者require载入脚本。我喜欢把它们封装到一个函数里，需要载入脚本的时候调用这个函数。这样可以在函数里做一些判断，比如说是否引入过这个文件，或者增加一些调用规则等，维护起来比较方便。
幸好有了这样的习惯，所以我可以马上把debug_backtrace的一些想法应用到整个项目中。
总体来说debug_backtrace有很好的灵活性，只要稍加利用，可以实现一些有趣的功能。但同时我发现它并不是很好控制，因为每次调用任何一个方法或函数，都有可能改变它的值。如果要使用它来做一些逻辑处理（比如说我本文提到的一些想法），需要一个拥有良好规范准则的系统，至少在加载文件方面吧。
以上就是PHP debug_backtrace的胡思乱想的内容，更多相关内容请关注PHP中文网（www.php.cn）！