肯定是Google了。英文的比中文的更新快。現在看百度出來的，都是抄來抄去，關鍵是抄的人自己都沒經過驗證的。一般上stackoverflow。那裡一般可以找到答案。

1.可以採用排除法，一步步還原改動的程式碼，直的不報錯為止，這樣可查出問題所在;

2.把你報錯的異常放在論壇上面發貼求教，相關的論壇有csdn,iteye等等;

3.打斷點除錯，一步步調式哪裡程式碼出現問題，具體問題具體分析;如果是jar包裡面出現的問題，檢視是不是版本問題導制的;

4.如果檢視程式碼沒有問題，但是程式依然報錯，可看看是不是做的一些特殊操作比如讀取檔案流或迴圈等，是不是記憶體溢位等，這個可能是程式碼質量問題，需要最佳化;

1. stackoverflow, github, msdn, csdn先走一波，有解決方案的看下能否套用

2. 以上都查不到，恭喜你，打斷點，加日誌，找到問題所在的程式碼。看報錯資訊，然後查文件。

3. 如果還是不行，試著自己寫，不要用第三方。

沒有程式設計問題是stack overflow和Google解決不了的，假設你在程式設計中遇到了問題，你自己解決不了、你周圍的的人都解決不了的時候，我覺得stack overflow、Google是你最好、也是最後的幫手。

作為一個程式設計師，我覺得Google、stack overflow是你必須要學會使用的兩個工具，這兩個工具本身並沒有使用門檻，只不過因為一些眾所周知的原因，很多人不能使用Google和stack overflow這兩款工具。

Google主要還是方便，而且很多程式設計問題都需要用到英文搜尋，當然現在百度在專業能力上也提升明顯，不過跟Google也還是有比較大的差距，因此我還是強烈建議要學會使用Google，這會幫你在工作、學習上事半功倍。假設Google確實因為某些原因沒辦法很好的使用，我也建議你至少要會使用Bing搜尋。

現在可以說stack overflow上沒有你找不到的問題了，從IDE環境安裝問題，到各類程式語言問題。演算法問題，資料結構問題，除錯，重構等等，幾乎這裡就沒有你找不到的答案，可以說在stack overflow上你可以找到任何解決方案，並且上面的回答者基本上都是非常有經驗，而且都是實際中遇到的問題分享出來的，這個工具一定要會使用。同理，除了stack overflow這個專業的垂直程式設計師問答社群，你也可以使用Quora這個綜合問答社群，這上面也能找到很多問題的答案。

一些比較優秀的文字編輯器：Emacs/Vim，Visual Studio Code，Sublime Text，Atom，Ultraedit，Hbuilder等。

一些比較非常出色的IDE整合開發環境：visual studio，IntelliJ IDEA，PhpStorm，Haskell for Mac ，eclipse，WebStorm，GoLand，CLion，Android Studio，Xcode，QT等。

macOS平臺比較好的第三方包管理工具：Fink，Macports，Homebrew等。

一些比較好的終端工具：Zoc7，iTerm2，Cmder，terminus，hyper等。

一些比較好的筆記軟體、markdown工具、效率工具：Evernote，有道雲筆記，為知筆記，Ulysses，MWeb，FileZilla，Snipaste，Kantu等。

虛擬機器軟體、容器軟體：Parallels Desktop，VMWare Fusion，Virtual Box，Docker等。

知識，工具，方法，Debug的三個層面。

搜尋主要解決知識層面的問題。百度當然不行，主要是stack overflow和google. 對於常規問題，它們大多能解決。

對於詭異的問題，靠的是正確的方法和思路。

Bug定位的過程主要是用折半查詢來縮小範圍，用區域性替換來驗證問題。這兩個方法可以說是Debug的基礎和核心。當然，用簡化的方式搭建最小測試環境也很重要。

其它經驗：

Debugging（或Troubleshooting）也是一項有成就感的工作，祝新老軟硬體工程師Debug愉快！

筆者不同意下面網友的回答。程式設計師如果解決bug的水平停留在百度，那麼本質上只是一個“面向搜尋引擎的程式碼搬運工”，是不合格的程式設計師。

程式設計師對面bug，正確的“開啟方式”是像福爾摩斯和柯南那樣，尋找線索、運用邏輯推理來縮小問題可能的根因範圍，最終精準定位。

常用的方法有：

1. 壞境上下文變換法

2. 工具除錯法

3. 版本回溯對比法

4. 程式碼審計法

……

我是個程式設計師，職務是linux底層驅動工程師。平時的主要工作是除錯驅動，但產品遇到諸如宕機、重啟、不開機之類的問題時，也要參與查詢原因。一部分問題，確實可以檢視相關的log，然後百度這些log的關鍵字來解決；但更多的問題，牽扯的條件太多，並不是簡單的百度就能解決的。

觀察了周圍同事們的做法，我總結出以下幾種解決方法：

百度因為競價排名的原因，搜尋出來的結果有很多廣告的成分，所以有時候要翻好幾頁才能看到一條相關的答案，有些甚至要翻幾十頁。

因為百度搜索使用的是SEO技術，即普通使用者可以透過最佳化網站內容來提升關鍵詞排名。

而這就會導致一個問題：你搜索關鍵詞後展現出來的結果是有人想要讓你看到的，並不是質量最好的。

也就是說，百度搜索結果被人為干預了。所以百度一直被網民所詬病。

但百度搜索不出結果，未必是百度的原因，也有可能是自己輸入的搜尋詞不準確造成的。所以對於百度，我們要做到如下幾點:

不要把搜尋引擎當人，避免口語化搜尋，使用專業詞彙搜尋

常用關鍵詞，表達準確

01 過濾目標內容

命令：“+”“-”

用法：透過“+”和“-”來對搜尋結果進行過濾

比如在關鍵詞後加上“-推廣 -推廣連結”就可以排除搜尋結果中包含相應字樣的連結。如果你發現廣告還沒有排除乾淨，你也可以再加上“-廣告”通常就能徹底的消滅廣告。

02 搜尋包含某關鍵詞的內容

命令：“intitle”

用法：透過“intitle”命令指定搜尋結果中要包含的關鍵詞，注意“intitle”後邊連線的冒號是英文狀態下的。

03 搜尋某一個格式的檔案

命令：“filetype”

用法：透過“filetype”命令可以限制我們要搜尋檔案的型別，注意“filetype”後邊接的冒號也是英文狀態下的。

04 搜尋特定時間範圍的內容

命令：“時間..時間”

用法：透過“時間..時間”命令可以限制我們要搜尋的檔案的時間，注意兩個時間的中間頓號沒有空格。

相對百度，谷歌、必應對於技術搜尋，就相對準確許多，所以當你百度搜索不到時，嘗試下別的搜尋引擎，說不定會有新發現。

現在程式設計師使用的機器語言，都是國外的，更準確的說，都是美國的。所以很多論壇、資料等，都是英文。如果你只會用中文來搜尋，某些小眾的問題，當然搜不到啦。

所以，要學會使用英文關鍵字來搜尋。

有時候甚至要去國外的一些論壇來搜尋想要的答案，這就要求要有一定的英語閱讀能力，不能一看到英文帖就放棄。

有時候不管你如何搜尋，都找不到自己想要的答案，該怎麼辦呢？這種情況下，就只能硬著頭皮嘗試自己解決了。

或者，尋求同事或朋友的幫助，尋求大腦風暴，說不定就會有思路。

如果有些問題是因為新器件帶來的，還可以找到器件供應商，讓他們安排技術支援幫忙查詢原因。

除此之外，還可以把問題整理好，寫清發生的條件、復現步驟、測試方法、相關的LOG截圖等資料，去一些技術論壇發求助帖，尋找大牛的幫助。

做技術時間久了，發現有些問題確實無解，根本沒有辦法去解決它。

這時候，我一般會嘗試把它繞過，就是說，想辦法讓它無法復現，雖然問題還是存在，但是能把它掩蓋過去。

比如有些驅動在開機啟動時會載入不正常，那麼就讓它晚點啟動，或者手動載入。這也不失為一種解決問題的方法。

不管是百度還是Google，只是給我們提供了一種思路。如果在百度上有著明晃晃的答案，那說明這個問題就不是什麼難的問題。當遇到百度不出來答案的問題。我們要怎麼解決呢？其實這種問題，才能體現出一個人的能力。

1.從頭開始，一步一步找，找出每個可能出現問題的地方。

2.將問題細化，一個一個去解決。

找bug跟醫生看病的思路是一樣的，要對症下藥。得先把問題的根源找到，找到根源以後問題就容易處理了。搜尋引擎找不到的問題，說明這個問題不是一個常見的問題，具有獨特性，那麼從bug出現的路徑上一步一步去排查。必要時可以用排除法，儘可能的縮小排查範圍。另外，當軟體的業務邏輯比較繁多複雜的時候，一個結構清晰的架構能為你節省不少找bug的時間。還有，充分的單元測試能夠幫你減少出bug的機會。以上均為個人看法，歡迎討論！

首先作為一個程式設計師，一個優秀的程式設計師最最最重要的能力就是解決問題的能力。這裡解決問題的能力當然就包含了解決 bug 能力了

畢竟，程式設計師這一生，可能會寫無數個 bug ，沒有說哪個程式設計師敢保證自己寫的程式沒有 bug 。所以，寫了 bug ，遇到 bug 並不可怕，可怕的是你沒有解決 bug 的能力。

作為一個程式設計師，解決 bug 的途徑有哪些呢？我們來一起聊一聊！

其實，每個程式設計師在學習程式設計的時候，都會使用程式設計工具，而現在的開發工具，其實功能都很強大。如果你自己合理利用程式設計工具，都瞭解和懂得開發工具的一些技巧，其實不僅僅能夠提高開發效率，而且還能夠幫助你解決很多程式設計中的實際問題。

debug 除錯，大部分你常用的開發工具，都會有除錯模式的，簡而言之，就是你程式設計的時候，遇到了不是自己所想的結果的時候，你可以使用 debug 模式，來一步一步的除錯，在除錯模式下一般每一步都會顯示所執行的結果，你可以看看在哪一步出錯了，執行的結果與你預想的結果不對，那麼你就能夠找到問題所在了。

還有就是，開發工具的控制檯，都會提示出報錯資訊的，現在的開發工具，都會直接告訴你哪一行，報了什麼錯。其實，很容易定位到錯誤的。你只需要在程式設計的過程中積累經驗，知道報什麼錯，用什麼方法來解決就行啦。

可是，提示的報錯資訊，我不知道用什麼方法來解決的時候，該怎麼辦呢？這就是你需要積累的，也是問題中所描述的，就是透過搜尋引擎來找答案。

不對，這裡不應該是合理使用搜索引擎，應該是學會正確使用搜索引擎。比如：百度，你就不要用了，搜出一堆重複的資訊，而且廣告也多。作為程式設計師，建議你使用谷歌搜尋。

其實，你在程式設計中所遇到的幾乎所有的問題和 bug ，別人也同樣遇到過，因為不管是經驗豐富的老程式設計師，他技術再牛逼，也是初學者過來的，也都踩過你踩的坑。所以，網際網路是個好地方，裡面包含了你想要的問題的答案。

你只要把報錯資訊往搜尋引擎上一放，回車一下，很多關於這個 bug 的答案就出來很多，你只需要找到跟你一樣的 bug ，就能找到答案了。

在這裡必須提一下這個網站，所有的程式設計師有必要學會使用這個網站，其實，你程式設計中所遇到的問題，這個網站上幾乎都是由解答的。

Stack Overflow 可以說是最好的軟體程式類問答網站了，給軟體開發人員工作和學習提供了非常大的便利，以至於像小白，離了 Stack Overflow 簡直都不會寫程式了。

所以，建議大家一定要學會使用這個網站，對你程式設計肯定會有非常大的幫助的。

透過上面的方法，幾乎應該能夠解決到你所遇到的問題，但是，實在找不到答案的話，你可以問經驗比你豐富的老程式設計師，實在解決不了，那就換種方法吧！

我做開發20年，百度解決不了不超過十個難題。不過很多是基於經驗的積累，一些稀奇古怪的bug是這麼解決的，就是第二天早晨起來就想到解決方案了

我來說幾句。針對程式設計師百度不出來的bug我有幾點經驗分享：

多加日誌

程式碼的日誌非常關鍵，可以幫助我們實時地監測每個變數的賦值和邏輯的走向情況，當遇到問題時，可以透過抓取分析日誌資訊來快速定位問題的原因。就像醫生給患者看病一樣，一看二問三模四查，望聞問切，透過多方便的因素尋找病根。

日誌級別有五種：

DEBUG：開發過程中經常需要用到的除錯資訊，可以快速幫助定位問題

INFO：列印一些程式執行過程中的資訊，一般是重要的程式碼節點處需要加上，但不能濫用避免列印過多

WARNING：程式碼存在潛在的問題，如果不能及時修復，可能會引起嚴重錯誤

ERROR：嚴重的問題,程式碼執行出錯，但不會導致程式退出

CRITICAL：不可控制的嚴重錯誤導致程式無法執行

開發過程中儘量在關鍵程式碼出加上一些DEBUG日誌，在一些關鍵的邏輯性很強的程式碼處多加一些INFO日誌，針對可能會出問題的地方要加上ERROR錯誤捕獲，凡是有WARNNING的地方要多加註意，儘量避免WARNNING的出現。

程式碼除錯

一個不會除錯的程式設計師就是一個不合格的程式設計師。程式碼除錯太關鍵了，可以幫助程式設計師梳理編碼邏輯，覆盤問題，能夠迅速找到問題的根源，可以說大部分的BUG都可以透過除錯解決。而且當前很多的IDE開發工具都支援程式碼除錯，功能強大，比如vscode，eclipse，idea，android studio等。

程式碼除錯需要會加斷點、逐行除錯、跳進原始碼內部檢視原始碼、檢視變數等：

看原始碼

有時候的bug並不是明顯的程式碼錯誤導致，可能是呼叫各種第三方庫發生的異常，此時需要定位到原始碼裡面找原因。

會用搜索引擎如Google,Bing

目前對於程式設計師來說比較友好的兩個搜尋引擎一個Google，另一個是Bing，大部分的bug問題都能夠在這上面搜尋的到。

一般大陸Goole搜尋不能夠直接使用，需要翻牆才行，具體的方法可以上網搜尋。

保持記錯的習慣，形成經驗

程式設計師保持記錯的習慣很重要，話說：我們不能在同一個問題上栽跟頭。良好的記筆記習慣可以讓我們面對各種bug時，可以根據自己的經驗更快地找到解決方法。當然，如果你的記性夠好也可以不用記筆記。

善於請教經驗豐富的同事或朋友

每一個程式設計師不可能什麼都知道，人無完人， 任何人都有自己的優缺點，我們可以多多請教有經驗的同事或朋友幫助解決bug。不過，求人辦事不能太頻繁，畢竟很多問題都得靠自己摸索，經常麻煩別人也會影響他人的正常生活和工作。

會用減邏輯法

有一個解決疑難雜症bug的好方法就是減邏輯法，通常我們寫的功能會包含很多的業務邏輯，而往往出問題的地方是某一個很小的地方，此時程式碼太多、無關的業務太多對於我們除錯來說是非常困難的，會影響到我們排查問題的效率。此時，我們需要註釋掉跟此bug毫無相關的業務邏輯程式碼，只保留一些跟bug有關係的程式碼，這樣能夠方便我們快速定位問題，找到解決bug的方法。

會使用替代的方法

有時候，我們寫的程式碼出了bug，花了很長時間都無法排查並解決，此時不要慌，你可以另闢蹊徑，換一種實現方式來實現。有時候這樣的效果更佳，你也不用再去絞盡腦汁地定位bug的原因，同時你還能學到了另一種解決問題的方法。

總結

解決bug的方法千千萬，要回綜合使用各種方法來定位問題，解決問題。其次，心態很重要，遇到bug時千萬不要慌，從容應對方能出奇制勝。