<转>利用PHP的debug_backtrace函数，实现PHP文件权限管理、动态加载

可能大家都知道，php中有一个函数叫debug_backtrace，它可以回溯跟踪函数的调用信息，可以说是一个调试利器。

好，来复习一下

01one();02 03function one() {04two();05}06 07function two() {08three();09}10 11function three() {12print_r( debug_backtrace() );13}14 15/*16输出：17Array18(19[0] => Array20(21[file] => D:/apmserv/www/htdocs/test/debug/index.php22[line] => 1023[function] => three24[args] => Array25(26)27 28)29 30[1] => Array31(32[file] => D:/apmserv/www/htdocs/test/debug/index.php33[line] => 634[function] => two35[args] => Array36(37)38 39)40 41[2] => Array42(43[file] => D:/apmserv/www/htdocs/test/debug/index.php44[line] => 345[function] => one46[args] => Array47(48)49 50)51 52)53*/

顺便提一下类似的函数： debug_print_backtrace ，与之不同的是它会直接打印回溯信息。

回来看 debug_backtrace ，从名字来看用途很明确，是让开发者用来调试的。直到有一天我注意到它返回的 file 参数， file 表示函数或者方法的调用脚本来源（在哪个脚本文件使用的）。忽然我想到，如果当前脚本知道调用来源，那是否可以根据这个来源的不同，来实现一些有趣的功能，比如文件权限管理、动态加载等。

实战

实现魔术函数 

获取当前函数或方法的名称 

尽管PHP中已经有了 __FUNCTION__ 和 __METHOD__ 魔术常量，但我还是想介绍一下用 debug_backtrace 获取当前函数或者方法名称的方法。

代码如下：

01//函数外部输出getFuncName的值02echo getFuncName();03 04printFuncName();05 06Object::printMethodName();07 08//调用了上面两个函数后，再次在外部输出getFuncName，看看是否有‘缓存’之类的问题09echo getFuncName();10 11 12 13function printFuncName() {14echo getFuncName();15}16 17class Object {18static function printMethodName() {19echo getFuncName();20}21}22 23/**24 * 获取当前函数或者方法的名称25 * 函数名叫getFuncName，好吧，其实method也可以当做function，实在想不出好名字26 *27 * @return string name28 */29function getFuncName() {30$debug_backtrace = debug_backtrace();31//如果函数名是以下几个，表示载入了脚本，并在函数外部调用了getFuncName32//这种情况应该返回空33$ignore = array(34'include',35'include_once',36'require',37'require_once'38);39//第一个backtrace就是当前函数getFuncName，再上一个（第二个）backtrace就是调用getFuncName的函数了40$handle_func = $debug_backtrace[1];41if( isset( $handle_func['function'] ) && !in_array( $handle_func['function'], $ignore ) ) {42return $handle_func['function'];43}44return null;45}46 47 48//输出：49//null50//printFuncName51//printMethodName52//null

View Code

看上去没有问题，很好。

加载相对路径文件

如果在项目中要加载相对路径的文件，必需使用include或者require之类的原生方法，但现在有了debug_backtrace，我可以使用自定义函数去加载相对路径文件。

新建一个项目，目录结构如下：

我想 在index.php 中调用自定义函数，并使用相对路径去载入 package/package.php ，并且在 package.php 中使用同样的方法载入 _inc_func.php 

三个文件的代码如下（留意 index.php 和 package.php 调用 import 函数的代码）：

index.php：

01<?php02 03import( './package/package.php' );04 05/**06 * 加载当前项目下的文件07 *08 * @param string $path 相对文件路径09 */10function import( $path ) {11//获得backstrace列表12$debug_backtrace = debug_backtrace();13//第一个backstrace就是调用import的来源脚本14$source = $debug_backtrace[0];15 16//得到调用源的目录路径，和文件路径结合，就可以算出完整路径17$source_dir = dirname( $source['file'] );18require realpath( $source_dir . '/' . $path );19}20 21?>

View Code

package.php：

1<?php2 3echo 'package';4 5import( './_inc_func.php' );6 7?>

View Code

_inc_func.php：

1<?php2 3echo '_inc_func';4 5?>

View Code

运行index.php：

1//输出：2//package3//_inc_func

View Code

可以看到，我成功了。

思考：这个方法我觉得非常强大，除了相对路径之外，可以根据这个思路引伸出相对包、相对模块之类的抽象特性，对于一些项目来说可以增强模块化的作用。

管理文件调用权限

我约定一个规范：文件名前带下划线的只能被当前目录的文件调用，也就是说这种文件属于当前目录‘私有’，其它目录的文件不允许载入它们。

这样做的目的很明确：为了降低代码耦合性。在项目中，很多时候一些文件只被用在特定的脚本中。但是经常发生的事情是：一些程序员发 现这些脚本有自己 需要用到的函数或者类，因此直接载入它来达到自己的目的。这样的做法很不好，原本这些脚本编写的目的仅仅为了辅助某些接口实现，它们并没有考虑到其它通用 性。万一接口内部需要重构，同样需要改动这些特定的脚本文件，但是改动后一些看似与这个接口无关脚本却突然无法运行了。一经检查，却发现文件的引用错综复 杂。

规范只是监督作用，不排除有人为了一己私欲而违反这个规范，或者无意中违反了。最好的方法是落实到代码中，让程序自动去检测这种情况。

新建一个项目，目录结构如下。

那么对于这个项目来说， _inc_func.php 属于 package 目录的私有文件，只有 package.php 可以载入它，而 index.php 则没有这个权限。

package目录是一个包， package.php 下提供了这个包的接口，同时 _inc_func.php 有 package.php 需要用到的一些函数。 index.php 将会使用这个包的接口文件，也就是 package.php

它们的代码如下

index.php：

01<?php02 03header("Content-type: text/html; charset=utf-8");04 05//定义项目根目录06define( 'APP_PATH', dirname( __FILE__ ) );07 08import( APP_PATH . '/package/package.php' );09//输出包的信息10Package_printInfo();11 12/**13 * 加载当前项目下的文件14 *15 * @param string $path 文件路径16 */17function import( $path ) {18 19//应该检查路径的合法性20$real_path = realpath( $path );21$in_app = ( stripos( $real_path, APP_PATH ) === 0 );22if( empty( $real_path ) || !$in_app ) {23throw new Exception( '文件路径不存在或不被允许' );24}25 26include $real_path;27}28 29?>

View Code

_inc_func.php：

1<?php2 3function _Package_PrintStr( $string ) {4echo $string;5}6 7?>

View Code

package.php：

01<?php02 03define( 'PACKAGE_PATH', dirname( __FILE__ ) );04 05//引入私有文件06import( PACKAGE_PATH . '/_inc_func.php' );07 08function Package_printInfo() {09_Package_PrintStr( '我是一个包。' );10}11 12?>

View Code

运行index.php：

1//输出：2//我是一个包。

整个项目使用了 import 函数载入文件，并且代码看起来是正常的。但是我可以在 index.php 中载入 package/_inc_func.php 文件，并调用它的方法。

index.php中更改import( APP_PATH . '/package/package.php' );处的代码，并运行：

1import( APP_PATH . '/package/_inc_func.php' );2 3_Package_PrintStr( '我载入了/package/_inc_func.php脚本' );4 5//输出：6//我载入了/package/_inc_func.php脚本

View Code

那么，这时可以使用 debug_backtrace 检查载入 _inc_func.php 文件的路径来自哪里，我改动了 index.php 中的 import 函数，完整代码如下：

01/**02 * 加载当前项目下的文件03 *04 * @param string $path 文件路径05 */06function import( $path ) {07 08//首先应该检查路径的合法性09$real_path = realpath( $path );10$in_app = ( stripos( $real_path, APP_PATH ) === 0 );11if( empty( $real_path ) || !$in_app ) {12throw new Exception( '文件路径不存在或不被允许' );13}14 15$path_info = pathinfo( $real_path );16//判断文件是否属于私有17$is_private = ( substr( $path_info['basename'], 0, 1 ) === '_' );18if( $is_private ) {19//获得backstrace列表20$debug_backtrace = debug_backtrace();21//第一个backstrace就是调用import的来源脚本22$source = $debug_backtrace[0];23 24//得到调用源路径，用它来和目标路径进行比较25$source_dir = dirname( $source['file'] );26$target_dir = $path_info['dirname'];27//不在同一目录下时抛出异常28if( $source_dir !== $target_dir ) {29$relative_source_file = str_replace( APP_PATH, '', $source['file'] );30$relative_target_file = str_replace( APP_PATH, '', $real_path );31$error = $relative_target_file . '文件属于私有文件,' . $relative_source_file . '不能载入它。';32throw new Exception( $error );33}34}35 36include $real_path;37}

View Code

这时再运行 index.php ，将产生一个致命错误：

1//输出：2//致命错误：/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 ，将获取不到路径的信息。

例：

01call_user_func('import');02 03function import() {04print_r( debug_backtrace() );05}06 07 08/*09输出：10Array11(12[0] => Array13(14[function] => import15[args] => Array16(17)18 19)20 21[1] => Array22(23[file] => F:/www/test/test/index.php24[line] => 325[function] => call_user_func26[args] => Array27(28[0] => import29)30 31)32 33)34*/

View Code

注意输出的第一个 backtrace ，它的调用源路径 file 没有了，这样一来我之前的几个例子将会产生问题。当然可能你注意到第二个 backtrace ，如果第一个没有就往回找。但经过实践是不可行的，之前我就碰到这种情况，同样会有问题，但是现在无法找回那时的代码了，如果你发现，请将问题告诉我。就目前来说，最好不要使用这种方法，我有一个更好的解决办法，就是使用PHP的反射API。

使用反射

使用反射API可以知道函数很详细的信息，当然包括它声明的文件和所处行数

01call_user_func('import');02 03function import() {04$debug_backtrace = debug_backtrace();05$backtrace = $debug_backtrace[0];06if( !isset( $backtrace['file'] ) ) {07//使用反射API获取函数声明的文件和行数08$reflection_function = new ReflectionFunction( $backtrace['function'] );09$backtrace['file'] = $reflection_function->getFileName();10$backtrace['line'] = $reflection_function->getStartLine();11}12print_r($backtrace);13}14 15/*16输出：17Array18(19[function] => import20[args] => Array21(22)23 24[file] => F:/www/test/test/index.php25[line] => 526) 

View Code

可以看到通过使用反射接口 ReflectionMethod 的方法， file 又回来了。

类方法的反射接口是 ReflectionMethod ，获取声明方法同样是 getFileName 。

总结

在一个项目中，我通常不会直接使用 include 或者 require 载入脚本。我喜欢把它们封装到一个函数里，需要载入脚本的时候调用这个函数。这样可以在函数里做一些判断，比如说是否引入过这个文件，或者增加一些调用规则等，维护起来比较方便。

幸好有了这样的习惯，所以我可以马上把 debug_backtrace 的一些想法应用到整个项目中。

总体来说 debug_backtrace 有很好的灵活性，只要稍加利用，可以实现一些有趣的功能。但同时我发现它并不是很好控制，因为每次调用任何一个方法或函数，都有可能改变它的值。如果要使用它来做一些逻辑处理（比如说我本文提到的一些想法），需要一个拥有良好规范准则的系统，至少在加载文件方面吧。

读后感：

这篇文章是转自一位网友的，它让我对PHP的debug_backtrace()函数有了更深的理解，不过，我还是不太赞成作者对该函数的如此应用：

1、多次调用debug_backtrace()，会出现性能问题，耗内存；

2、debug_backtrace()函数在日志调试跟踪的时候比较有用、好用；

3、接下来再去研究一下该函数在 PHP调试及日志系统 中的应用；