優(yōu)先解決那些可重現的，可重現的 bug 特別好找，反復調試測試就好了，先把好解決的干掉，這樣最節(jié)約時間。

對于某些 bug 沒有頭緒或者現象古怪不知道從哪里下手，找有經驗的同事問一下思路，因為在那種開發(fā)多年的大型系統(tǒng)里，經常會反復出現同樣原因的 bug，原因都類似，改了一處，過一陣子另外一處又冒出來，而且無法根治。比如：我那個系統(tǒng)里有個特別危險的 API，接口參數比較難用，一旦有人用錯了某些情況下就會出詭異的現象，解決很簡單，找到調用這個 API 的地方把調用方式寫對就好了。為什么不根治呢？因為要保持兼容性不能改接口了。Windows 系統(tǒng)里就好多這種爛 API。問下老員工吧，說不定他們都遇到過好多次了。

放大現象，有些 bug 現象不太明顯，那么就想辦法增大它的破壞性，把現象放大。這只是個思路，具體怎么放大只能根據具體的代碼來定。比如：美劇《豪斯醫(yī)生》里有一集，懷疑病人心肺有問題，就讓病人去跑步機上跑步，加重心肺負擔，從而放大癥狀。

二分法定位，把程序邏輯一點點注釋掉，看看還會不會出問題，類似二分查找的方法，逐步縮小問題范圍。

模擬現場，有時候我會問自己，如果我要實現 bug 描述的現象我要怎么寫代碼才行？比如：我遇到一個死鎖問題，但是檢查代碼發(fā)現所有的鎖都是配對的，沒有忘記解鎖的地方，而且鎖很簡單就是一個普通的臨界段，保護幾行賦值語句而已。這樣的代碼怎么寫才能讓他死鎖呢？我想如果讓我故意制造這樣一個現象，只有在上鎖的時候強制殺掉線程了。既然這樣就可以去看看有誰強殺線程了沒有。

制作工具，針對某些 bug 編寫一些調試輔助工具。比如，我那個系統(tǒng)沒有完善的崩潰報告，雖然也有 dump，但是分析出來的 callstack 經常不準。于是我為解決崩潰問題編寫了個工具，會自動掃描代碼，在每個函數入口和出口插入 log，以此來定位崩潰點。

掩蓋問題，雖然這樣做有點不厚道，但是有時不得不這么做。有些 bug 找不到真正的 root cause，但是又要在規(guī)定時間內解決，那么我們就可以治療癥狀而不去找病因。比如用 try catch 掩蓋一些奇怪的崩潰。不到萬不得已不要這么干，未來可能會付出更大代價。