本文示例代碼測試環境是Windows下的APMServ(PHP5.2.6) 簡述 可能大家都知道,php中有一個函數叫debug_backtrace,它可以回溯跟蹤函數的調用信息,可以說是一個調試利器。 好,來複習一下。 one(); function one() { two(); } functi ...
本文示例代碼測試環境是Windows下的APMServ(PHP5.2.6)
簡述
可能大家都知道,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__魔術常量,但我還是想介紹一下用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
三個文件的代碼如下(留意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.php:
<?php echo '_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有很好的靈活性,只要稍加利用,可以實現一些有趣的功能。但同時我發現它並不是很好控制,因為每次調用任何一個方法或函數,都有可能改變它的值。如果要使用它來做一些邏輯處理(比如說我本文提到的一些想法),需要一個擁有良好規範準則的系統,至少在載入文件方面吧。