xdebug下載地址:http://www.xdebug.org/download.php
版本選擇: xdebug有Non-thread-safe(非線程安全)、thread-safe(線程安全)
寫一個test.php，內容爲<?php phpinfo(); ?>，搜索"Thread Safety" enable爲線程安全版、disable爲非線程安全版
選擇VC6還是VC9?
標明 MSVC9 (Visual C++ 2008) 的是VC9
如果你在apache1或者apache2下使用PHP，你應該選擇VC6的版本
如果你在IIS下使用PHP應該選擇VC9的版本
VC6的版本使用visual studio6編譯
VC9使用Visual Studio 2008編譯，並且改進了性能和穩定性。VC9版本的PHP需要你安裝Microsoft 2008 C++ Runtime
不要在apache下使用VC9的版本
Xdebug安裝:
將下載的php_xdebug-2.1.0-5.2-vc6.dll放到C:\php5\ext目錄，重命名爲php_xdebug.dll；
編輯php.ini，加入下面幾行：
[Xdebug]
extension=php_xdebug.dll
xdebug.profiler_enable=on
xdebug.trace_output_dir="X:\Projects\xdebug"
xdebug.profiler_output_dir="X:\Projects\xdebug"
後面的目錄“I:\Projects\xdebug”爲你想要放置Xdebug輸出的數據文件的目錄，可自由設置。
4． 重啓Apache；
5． 寫一個test.php，內容爲<?php phpinfo(); ?>，如果輸出的內容中有看到xdebug，說明安裝配置成功。
Xdebug使用
Xdebug使用之開始調試：
我們先寫一個可以導致執行出錯的程序，例如嘗試包含一個不存在的文件。
testXdebug.php
<?php
require_once(‘abc.php’);
?>
然後通過瀏覽器訪問，我們驚奇地發現，出錯信息變成了彩色的了：
不過除了樣式改變，和我們平時打印的出錯信息內容沒什麼不同，意義不大。好，我們繼續改寫程序：
testXdebug2.php
<?php
testXdebug();
function testXdebug() {
require_once('abc.php');
}
?>
輸出信息：
發現了什麼？ Xdebug跟蹤代碼的執行，找到了出錯的函數testXdebug()。
我們把代碼再寫得複雜一些：
testXdebug3.php
<?php
testXdebug();
function testXdebug() {
requireFile();
}
function requireFile() {
require_once('abc.php');
}
?>
輸出信息：
'
呵呵，也就是說Xdebug具有類似於Java的Exception的“跟蹤回溯”的功能，可以根據程序的執行一步步跟蹤到出錯的具體位置，哪怕程序中的調用很複雜，我們也可以通過這個功能來理清代碼關係，迅速定位，快速排錯。
Xdebug配置
第一部分：基本特徵:
相關參數設置
xdebug.default_enable
類型：布爾型 默認值：On
如果這項設置爲On，堆棧跟蹤將被默認的顯示在錯誤事件中。你可以通過在代碼中使用xdebug_disable()來禁止堆疊跟蹤的顯示。因爲這是xdebug基本功能之一，將這項參數設置爲On是比較明智的。
xdebug.max_nesting_level
類型：整型 默認值：100
The value of this setting is the maximum level of nested functions that are allowed before the script will be aborted.
限制無限遞歸的訪問深度。這項參數設置的值是腳本失敗前所允許的嵌套程序的最大訪問深度。
第二部分：堆棧跟蹤:
相關參數設置
xdebug.dump_globals
類型：布爾型 默認值：1
限制是否顯示被xdebug.dump.*設置定義的超全局變量的值
例 如，xdebug.dump.SERVER = REQUEST_METHOD,REQUEST_URI,HTTP_USER_AGENT 將打印 PHP 超全局變量 $_SERVER['REQUEST_METHOD']、$_SERVER['REQUEST_URI'] 和 $_SERVER['HTTP_USER_AGENT']。
xdebug.dump_once
類型：布爾型 默認值：1
限制是否超全局變量的值應該轉儲在所有出錯環境(設置爲Off時)或僅僅在開始的地方(設置爲On時)
xdebug.dump_undefined
類型：布爾型 默認值：0
如果你想從超全局變量中轉儲未定義的值，你應該把這個參數設置成On，否則就設置成Off
xdebug.show_exception_trace
類型：整型 默認值：0
當這個參數被設置爲1時，即使捕捉到異常，xdebug仍將強制執行異常跟蹤當一個異常出現時。
xdebug.show_local_vars
類型：整型 默認值：0
當這個參數被設置爲不等於0時，xdebug在錯環境中所產生的堆棧轉儲還將顯示所有局部變量，包括尚未初始化的變量在最上面。要注意的是這將產生大量的信息，也因此默認情況下是關閉的。
第三部分：分析PHP腳本
相關參數設置
xdebug.profiler_append
類型：整型 默認值：0
當這個參數被設置爲1時，文件將不會被追加當一個新的需求到一個相同的文件時(依靠xdebug.profiler_output_name的設置)。相反的設置的話，文件將被附加成一個新文件。
xdebug.profiler_enable
類型：整型 默認值：0
開放xdebug文件的權限，就是在文件輸出目錄中創建文件。那些文件可以通過KCacheGrind來閱讀來展現你的數據。這個設置不能通過在你的腳本中調用ini_set()來設置。
xdebug.profiler_output_dir
類型：字符串 默認值：/tmp
這個文件是profiler文件輸出寫入的，確信PHP用戶對這個目錄有寫入的權限。這個設置不能通過在你的腳本中調用ini_set()來設置。
xdebug.profiler_output_name
類型：字符串 默認值：cachegrind.out%p
這個設置決定了轉儲跟蹤寫入的文件的名稱。
第四部分：遠程Debug
相關參數設置
xdebug.remote_autostart
類型：布爾型 默認值：0
一般來說，你需要使用明確的HTTP GET/POST變量來開啓遠程debug。而當這個參數設置爲On，xdebug將經常試圖去開啓一個遠程debug session並試圖去連接客戶端，即使GET/POST/COOKIE變量不是當前的。
xdebug.remote_enable
類型：布爾型 默認值：0
這個開關控制xdebug是否應該試着去連接一個按照xdebug.remote_host和xdebug.remote_port來設置監聽主機和端口的debug客戶端。
xdebug.remote_host
類型：字符串 默認值：localhost
選擇debug客戶端正在運行的主機，你不僅可以使用主機名還可以使用IP地址
xdebug.remote_port
類型：整型 默認值：9000
這個端口是xdebug試着去連接遠程主機的。9000是一般客戶端和被綁定的debug客戶端默認的端口。許多客戶端都使用這個端口數字，最好不要去修改這個設置。
注意：所有以上參數修改後，要重啓Apache才能生效！
Xdebug調試
其實PHP函數debug_backtrace()也有類似的功能，但是要注意debug_backtrace()函數只在PHP4.3.0之後版本及
PHP5中才生效。這個函數是PHP開發團隊在PHP5中新增的函數，然後又反向移植到PHP4.3中。
Xdebug使調試信息更加美觀
Xdebug 擴展加載後，Xdebug會對原有的某些PHP函數進行覆寫，以便好更好地進行Debug。比如var_dump()函數，我們知道通常我們需要在函數前 後加上”<pre>…</pre>”才能夠讓輸出的變量信息比較美觀、可讀性好。但是加載了Xdebug後，我們不再需要這樣做 了，Xdebug不但自動給我們加上了<pre>標籤，還給變量加上顏色。
例：
<?php
$arrTest=array(
"test"=>"abc",
"test2"=>"abc2"
);
var_dump($arrTest);
?>
輸出：
看到了嗎？ 數組元素的值自動顯示顏色。
如果你還是希望使用PHP的var_dump函數 只要在php.ini關於xdebug的配置中加上 xdebug.overload_var_dump = Off 即可
Xdebug測試腳本執行時間
測試某段腳本的執行時間，通常我們都需要用到microtime()函數來確定當前時間。例如PHP手冊上的例子：
<?php
/**
* Simple function to replicate PHP 5 behaviour
*/
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}
$time_start = microtime_float();
// Sleep for a while
usleep(100);
$time_end = microtime_float();
$time = $time_end - $time_start;
echo "Did nothing in $time seconds\n";
?>
但是microtime()返回的值是微秒數及絕對時間戳（例如“0.03520000 1153122275”），沒有可讀性。所以如上程序，我們需要另外寫一個函數microtime_float()，來將兩者相加。
Xdebug自帶了一個函數xdebug_time_index()來顯示時間。
PHP腳本佔用的內存
有時候我們想知道程序執行到某個特定階段時到底佔用了多大內存，爲此PHP提供了函數memory_get_usage()。這個函數只有當PHP編譯時使用了--enable-memory-limit參數時纔有效。
Xdebug同樣提供了一個函數xdebug_memory_usage()來實現這樣的功能，另外xdebug還提供了一個xdebug_peak_memory_usage()函數來查看內存佔用的峯值。
WinCacheGrind
有 時候代碼沒有明顯的編寫錯誤，沒有顯示任何錯誤信息（如error、warning、notice等），但是這不表明代碼就是正確無誤的。有時候可能某段 代碼執行時間過長，佔用內存過多以致於影響整個系統的效率，我們沒有辦法直接看出來是哪部份代碼出了問題。這時候我們希望把代碼的每個階段的運行情況都監 控起來，寫到日誌文件中去，運行一段時間後再進行分析，找到問題所在。
回憶一下，之前我們編輯php.ini文件
加入
[Xdebug]
xdebug.profiler_enable=on
xdebug.trace_output_dir="I:\Projects\xdebug"
xdebug.profiler_output_dir="I:\Projects\xdebug"
這 幾行，目的就在於把執行情況的分析文件寫入到”I:\Projects\xdebug”目錄中去（你可以替換成任何你想設定的目錄）。如果你執行某段程序 後，再打開相應的目錄，可以發現生成了一堆文件，例如cachegrind.out.1169585776這種格式命名的文件。這些就是Xdebug生成 的分析文件。用編輯器打開你可以看到很多程序運行的相關細節信息，不過很顯然這樣看太累了，我們需要用圖形化的軟件來查看。
WinCacheGrind下載
在Windows平臺下，可以用WinCacheGrind(wincachegrind.souceforge.net)這個軟件來打開這些文件。可以直觀漂亮地顯示其中內容：
WinCacheGrind小結：
Xdebug提供了各種自帶的函數，並對已有的某些PHP函數進行覆寫，可以方便地用於調試排錯；Xdebug還可以跟蹤程序的運行，通過對日誌文件的分析，我們可以迅速找到程序運行的瓶頸所在，提高程序效率，從而提高整個系統的性能。
如果在linux下 你可以使用 kcachegrind 查看xdebug的日誌
php擴展之關於extension,zend_extension和zend_extension_ts
extension意爲基於php引擎的擴展
zend_extension意爲基於zend引擎的擴展
注：php是基於zend引擎的。暈了吧。
不同的擴展安裝後，在php.ini裏是用extension還是zend_extension，是取決於該擴展，有的擴展可能只能用zend_extension，如xdebug，也有的擴展可以用extension或zend_extension，如mmcache。
注：上面的結論不保證準確。zend_extension加載php擴展時需用全路徑，而extension加載時可以用相對extension_dir的路徑。
確定可以用zend_extension之後，還有下面幾種可能：
根據 PHP 版本，zend_extension 指令可以是以下之一：
zend_extension (non ZTS, non debug build)
zend_extension_ts ( ZTS, non debug build)
zend_extension_debug (non ZTS, debug build)
zend_extension_debug_ts ( ZTS, debug build)
ZTS：ZEND Thread Safety
可通過phpinfo()查看ZTS是否啓用，從而決定用
zend_extension還是zend_extension_ts，當然試一下怎麼生效也可以。