簡単な説明
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 を見てください。名前から判断すると、その目的は開発者によってデバッグのために使用されることが非常に明確です。ある日、それが返すファイルパラメータが関数またはメソッドの呼び出しスクリプトソース(どのスクリプトファイルで使用されるか)を表すことに気づきました。突然、現在のスクリプトが呼び出し元を知っている場合、ファイルのアクセス許可管理、動的読み込みなど、ソースに基づいていくつかの興味深い機能を実装できるのではないかと考えました。
実践的な戦闘
マジック関数の実装
現在の関数またはメソッドの名前を取得します
PHPにはすでに__FUNCTION__と__METHOD__のマジック定数がありますが、現在の関数またはメソッドを取得するためにdebug_backtraceを使用することを導入したいと思います。名前メソッド。
コードは次のとおりです:
//函数外部输出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
3 つのファイルをロードするためのコードは次のとおりです (インポート関数を呼び出す Index.php と package.php のコードに注意してください):
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.php:
<?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)!