如何調試Php?

最簡單的誰都會的調試(是麼?):
本來安裝php是沒問題 也能用了 但是又從書上抄了一些代碼來發現不能用, 那就用眼睛仔細的對著書本糾正一下代碼哈 肯定是你抄錯了 要麼是印刷錯了
比如 1(yi)跟l(el) 0(ling)跟O(大寫o)等

別笑哈 真的有人抄錯過 還讓我過去幫忙調試 過去我錄入進去(他的沒儲存) 就全對了

言歸正傳
Q: "為什麼要調試?"
A: 當然是因為程式錯啦. 你以為我有什麼別的答案?
Q: "可是我覺得我的程式應該沒錯啊!"
A: 不能出來期望的結果 當然是錯誤發生. 有這種思想的人是根本不具備調試觀念 更沒有調試能力.
Q: 那調試有什麼用?
A: 不管是你配置的php出錯 還是你的程式寫錯 還是你寫的正確的程式跟別人配置的php(比如免費空間)犯沖, 學會調試都能找出原因來
Q: 邏輯亂了能調試好麼?
A: 或許你偶爾改來改去改好了 以為是調試好了 其實那已經不是單純的調試, 而是反覆的用程式碼進行思考, 並且反覆的改代碼來"實踐"某個idea是否可行.
可以說是"調試邏輯"而非"調試代碼":
邏輯沒代碼或者亂代碼--調試/修改邏輯-->正確的邏輯->體現在代碼上,出來正確的代碼.
單純的調試代碼是:
正確的邏輯--編碼-->出錯的代碼--調試-->正確的代碼
所以調試可以分為:
1.調試邏輯, 2.調試代碼, 3.調試介面. 4. etc..
錯誤的邏輯是不可能出來正確的程式. 寫程式首先得把邏輯(流程)弄清楚, 然後才開始編碼.
合并在一起就是:
含糊的邏輯--調試邏輯-->正確的邏輯--編碼-->出錯的代碼--調試代碼-->正確的代阿馬
其中調試邏輯你可以利用"修改代碼"來輔助 免得腦子太累, 但是腦子必須動, 不能不思考亂改來改去, 而且不能跟 "調試代碼" 混在一起.
改小錯誤 常常混在一起 就解決了, 但是要養成分開的習慣, 對於大錯誤才能一樣輕鬆解決.

別慌
很初學者 一碰到錯誤就慌了, 腦子裡只知道"不行啊 錯了 慘了 找個人問問", 要冷靜下來 根據所學的知識去研究, 到底什麼是debug, 如何debug, 出錯了到底該幹什麼

基本調試:
1. 開啟調試功能: php.ini 裡 設定error_reporting = E_ALL以及 display_errors = On 重啟 web服務(apache)
2. 重新整理錯誤的頁面 查看錯誤提示 行號 檔案名稱
3. 開啟該檔案 定位到出錯行. 比如代碼 echo $abc[2];
4. 理解錯誤:
a. 查看手冊 理解錯誤含義 要能理解首先要理解語言 比如最簡單的 Undefined index 2 意思是數組不存在該下標 也就說明你訪問了某個數組不存在的元素
b. 如果已經知道如何改 就直接修改, 比如改成 echo $abc[0];
c. 不知道就顯示變數內容 在同樣的地方 加入 var_dump($abc); 重新整理頁面 看看$abc這個東西到底包含了什麼元素
d. 認為本該存在 $abc[2]的, 那就尋找錯誤源, 往上回朔, 或者用 var_dump(debug_backtrace());
必要的時候 var_dump($_POST, $_GET, $_COOKIE, $_SERVER....)

本人未用過單步調試 (step by step) 如果使用調試器相對簡單一點 可以暫停下來 看看變數的內容 到底是不是 中應該出現的值, 如果不是 又是哪裡產生這個值的

注意留意什麼是環境
環境:
為什麼全世界那麼多人沒事就你的有問題? 你的問題愛上了你 還是你愛上了你的問題?
其實"一方水土養一方人", 你的"環境"養你的bug.
平時閱讀書本/手冊, 注意記錄整理什麼是"環境".
$_GET $_POST $_COOKIE $_SESSION $_SERVER 這些是程式啟動並執行至關重要因素 當然還包括你自己搞出來的 $GLOBALS, 都可以var_dump他們 看看內容.
還有strtolower/strtoupper之類 跟setlocale()函數有關, 而預設值在linux下跟 getenv("LANG") getenv("LC_ALL") 之類有關(putenv不一定起作用)
還有其他的 比如php.ini的配置.
還有web伺服器配置, 比如apache支援某些函數而在別的伺服器下就不支援

btw1: 你的調試能力跟你的編碼能力是相互相成的, 根據你的編碼經驗你覺得還有什麼該注意的 可以提出來
btw2: 有些你或許覺得很簡單很平常, 但是想想你自己是不是真的做到了

 

-------------------------------- 以下內容比較羅嗦
對於你一眼就看出來的問題, 當然可以立即解決, 但是如果沒頭緒那就參考:
調試的大方向:
抓!
a. 擒賊先擒王, 最大的錯誤就是邏輯錯誤, 先審查一邊邏輯, 然後才是代碼關鍵的部位(跟錯誤可能相關的)
b. 順瓜摸根.., 有果必有因, 知道最終錯誤的"結果", 順著摸過去 就能發生錯誤的"原因", 比如
if ($logined) {
$a = 100;
}
$_SESSION['a'] = $a; 提示Undefined variable $a, 顯然要找產生$a變數的地方, 往上找到 if那塊 發現只有if true的時候才有$a於是改成
if ($logined) {
$a = 100;
} else {
$a = 0;
}

比如mysql的函數出錯 就有好多提示
提示 密碼錯誤: 看看是參數的密碼錯了 還是mysql伺服器設定的密碼錯了
提示 sql欄位不存在, 開啟phpmyadmin去表裡看看有哪些欄位 程式寫錯了還是忘記添加了 還是搞錯表了
提示句錯誤, 找mysql手冊 而不是php手冊

拆!
所謂萬眾一心 那個什麼什麼來著, 但是我們是一個人面對的一個"龐大"的代碼, 所以要來個"反之亦然", 把錯誤從代碼裡分開, 把多個錯誤拆開. 如此一來, 對於你來說只不過是多個小小的錯誤, 一個個消滅.

憶:
回想以前是不是碰到類似的錯誤提示, 那個時候是怎麼解決的. 如果沒有回想到, 那就應該找新的方法.
對於初學者來說, 反覆鍛煉很重要, 回憶能加強學過的能力/方法, 直到聯會貫通, 應用自如.

對比:
跟本文開頭說的差不多, 就是找正確的代碼來對比.
有時候是沒有相應的正確代碼的, 這個時候可以在腦子裡重新構思一個正確代碼來對比, 有點難 呵呵, 不過這樣是避免又照著錯誤的思路去想
再就是看看手冊, 根據手冊說明就知道其實應該如何 不該如何.

OO 思路
要求你的程式比較OO(不一定是對象, 但是結構/思路上有oo)
OO編程簡單說就是對象化, 每個類型的對象完成某個功能, 就像一隻老鼠只需要吃就能活, 一個對象/或者某部分代碼 只需要所期望的一些資料就能正常工作.
OO debug法就是首先要有個觀念: 我的某個對象(or代碼)只需要有一定的資料(環境下)就可以正常工作
如果
1. 有正常的資料也出錯 則說明是這個對象設計錯了
2. 傳入的資料不正常, 則說明使用這個對象的代碼調用錯了
高手或許覺得這條很"傻", 其實對於初學者(包括以前的我) 要形成這樣的觀念 以及一直使用這個觀念來調試, 卻是要到了很久之後 接近高手了 才懂.
有點像'拆'方法 不過區別在於調試的時候:
1. 取對象出來 可以單獨調試, 因為好的對象(or代碼) 只需要盡量簡單的資料, 複雜的資料可能在對象內部或者外部生存, 而不會跨出/入對象(也就是不會傳進來 也不會傳出去)
2. 對於web要快速調試, 並不一定要把對象的代碼全部掏出來, 只需要再調用對象的部分 添加一些用來查看對象語句, 比如var_dump($obj) var_dump($obj->myabc);
或者類似 echo $http->download(); 這樣的調用之前 手工設定一些自己熟悉的資料 比如:
$http->setUrl("http://localhost/abc.html");
直到確保這個對象工作正常了, 就可以暫時撇開這個對象的代碼了, 看看別的東西有沒有錯誤