參考：
https://www.toutiao.com/i6826310485114094091/
http://www.phpmianshi.com/?id=84
青銅 var_dump/die打印變量值信息單步調試
是最簡單粗暴有效的解決問題方法。高級一點的是使用打印日誌。
白銀 會設置各種錯誤日誌的記錄和顯示，並根據各種錯誤日誌分析錯誤或者搜索別人的解決方案
php.ini 設置錯誤記錄
display_errors = On error_reporting = E_ALL | E_STRICT error_log = /data/wwwlogs/php_errors.log display_startup_errors = On log_errors = On
php-fpm.conf 設置錯誤日誌記錄並記錄慢日誌
error_log = /data/wwwlogs/php-fpm.error.log log_level = warning request_slowlog_timeout = 1 slowlog = /data/wwwlogs/php-fpm.slow.log
nginx 設置錯誤日誌記錄
error_log /data/wwwlogs/error_nginx.log crit;
查看linux系統日誌
tail -f /var/log/messages
能熟練根據各種錯誤日誌排查問題，基本已經可以解決大部分的異常問題。
鉑金 存在多個版本的php或php-cli與php-fpm加載不同的配置
存在多個版本的php，懂得通過which php來看是哪個PHP。
當php-cli與php-fpm得到的執行情況不一樣，php-cli下可以通過php -i |grep php.ini看加載了哪個php.ini。
fpm下通過phpinfo()函數可以看加載了哪個php.ini。
鑽石 使用strace/tcpdump工具跟蹤程序或抓包
strace可以用來查看系統調用的執行，使用strace php test.php，或者strace -p 進程ID。strace就可以幫助你透過現象看本質，掌握程序執行的過程。這個手段是在大型網站，大公司裏最常用的。如果當然strace對於PHP 代碼裏的死循環是解決不了的。比如你發現一個php-fpm進程CPU100%了，strace恐怕是解決不了的。因爲strace是看系統調用，一般都 是IO類操作，既然是IO密集，那CPU一定不可能是100%。
tcpdump可以抓到網卡的數據通信過程，甚至數據內容也可以抓到。使用tcpdump可以看到網絡通信過程是什麼樣的，如何時發起了TCP SYN3次握手，何時發送FIN包，何時發送RST包。這是一個基本功，如果不懂tcpdump，證明不具備網絡問題解決能力。
星耀 統計函數調用的耗時和成功率，分析系統慢的主要原因
使用xhporf/xdebug導出PHP請求的調用過程，然後分析每個函數調用的過程和耗時。能夠分析PHP程序的性能瓶頸，找出可以優化的點。
另外一個對於網絡服務的調用，如mysql查詢，curl，其他API調用等，通過記錄起始和結束時microtime，返回的是不是false， 可以得到調用是否成功，耗時多少。
通過nginx access.log 找到返回慢的主要接口：
查詢接口響應時間大於1秒的請求數量
grep user_msg.php access.log |grep POST |awk -F'up_resp_time' '{print $2}' |awk -F'\"' '$3>1{print $3}'|wc -l
通過php-fpm.slow.log 查看接口什麼地方調用比較慢：
查詢慢的函數調用比例：
grep -E 'script_filename.*user_msg' -A 3 php-fpm.slow.log | awk '{print $2}' |grep -v = |sort |uniq -c
王者 gdb使用
gdb是C/C++調試程序的利器，需要具備一定C/C++功底的程序員纔會能熟練使用gdb。上面說的strace無法跟蹤php程序CPU100%，而gdb是可以跟蹤的。另外gdb也可以解決php程序core dump的問題。