最近整理了我原創(chuàng)的 140 篇編程經驗和技術文章，歡迎大家閱讀，一起成長！指路：https://t.1yb.co/ARnD

大家好，我是魚皮。

學編程的過程中，我們會遇到各式各樣的 Bug，也常常因為它們而感到頭禿。

但隨著你不斷解決 Bug、積累經驗，就會發(fā)現(xiàn)其實解決 Bug 也是有套路的。

今天分享下魚皮自己總結的解決 Bug 套路，幫助大家提高編程學習效率，保護頭發(fā)。

解決 Bug 套路總結

本文大綱：

準備工作

其實改 Bug 的過程就跟破案是一樣的。

首先，在急著去搜索問題、上手寫代碼改 Bug 之前，先做這么幾件事。

1. 獲得更多信息

就像案發(fā)現(xiàn)場找目擊者、搜集證據一樣。

我們要搞清楚 Bug 何時發(fā)生？為什么會發(fā)生？在什么情況下發(fā)生？

用戶到底做了什么操作，才導致了 Bug ？

是每次都會出現(xiàn) Bug，還是說點兒背觸發(fā)了呢，如果是偶然觸發(fā)，是否可復現(xiàn)呢？

不能復現(xiàn)的 Bug，還叫 Bug 么？

這些信息，都很重要。如果可以的話，最好還能拿到用戶詳細的報錯原因、請求和響應，信息多了，才能幫助我們更精準地定位和分析問題。

2. 明確邊界

說白了，就是通過手上已有的信息，搞清楚要把這個 Bug 算在誰的頭上？

舉個例子，假如說用戶突然訪問不了你的網站了。這時千萬別自己先擱那傻傻分析和排查一通，而是可以先訪問下網站試試。要是你能訪問的話，說不定根本就不是 Bug，而是用戶自家的網線斷了！

企業(yè)開發(fā)中往往是多人協(xié)作，比如前端和后端、服務提供者和服務調用者，如何判斷是誰寫的 Bug 呢？

一般我們可以通過 接口 的請求參數(shù)和響應參數(shù)來劃分職責。

比如我是前端，請求你后端的接口，向你發(fā)送 "魚皮"，你必須要返回我 "狗頭"。結果最后出現(xiàn) Bug 時，我一看，我給你發(fā)送的是 "魚皮"，你卻給我 "魚頭" 了對吧，那顯然是你那邊的 Bug，雨我無瓜。

3. 保護現(xiàn)場

確定是自己的 Bug 后，如果是線上程序出了 Bug，記得先把當時的程序狀態(tài)保留下來，比如 dump 內存、下載日志，便于后面排查。

就和破案一樣，案發(fā)現(xiàn)場的東西千萬不能隨便亂碰，要不然可能就缺失了關鍵信息。

接下來看看如何解決 Bug。

自行解決

每個人的時間都很寶貴，出了問題時，建議先不要盲目地去問別人，而是自力更生，可以通過以下方式自己解決。

1. 自查

程序除了問題時，最直接的排查方式就是：對程序的報錯、已記錄的錯誤日志進行分析。

比如看到程序報錯 "db connection timeout"，顯然就是數(shù)據庫連接超時了，這個時候可以先去確認下是不是網絡和數(shù)據庫自身的問題，說不定就已經能解決 Bug 了。

2. 搜索引擎

俗話說得好，遇事不決問某度，這可能是大家最常用的解決 Bug 手段了。

但如今的某度搜索引擎對程序員不太友好，廣告多、內容過時、點進去后文不對題，這些都會成為你搜索的障礙。

那大家不妨試試這些技巧：

屏蔽廣告

在搜索詞后加上 "-advertisement" 可以快速屏蔽搜索的廣告信息：

站內搜索

使用 site:域名 + 搜索詞，可以在特定的網站內快速搜索，像現(xiàn)在大部分 Bug 的解決方案其實都在 CSDN：

關鍵詞搜索

使用某度搜索長句的時候，可以將錯誤信息中的關鍵詞拆解出來，比如版本號、數(shù)據庫類型等，使用空格進行連接疊加關鍵詞，可以更加精準搜索想要的結果，避免連接詞的干擾。

限定范圍

打開搜索工具，可以給搜索增加限定，比如時間、文件類型等：

當然，其他的搜索引擎也都有自己的搜索技巧，大同小異。

此外，大家也可以試試 開發(fā)者搜索 ，專門面向程序員的搜索引擎，純凈很多。而且看起來它的實現(xiàn)方式也很簡單，就只從開發(fā)者相關網站中搜索內容就行了。

3. 官方文檔

當我們使用一些冷門技術或者較新的技術時，國內的搜索引擎可能很難找到解決方案。

這時不妨打開官方文檔，直接搜索到和自己問題相關的部分，仔細閱讀一遍，說不定就發(fā)現(xiàn)其實是自己語法或參數(shù)寫錯了呢？

其實，很多 Bug 就是因為閱讀文檔不仔細而產生的！

對于組件庫、SDK、類庫、插件、API 的使用，我其實更傾向于去閱讀官方文檔，比較直接，一針見血。

4. Github

如果你使用的是開源的項目，那么可以試著在項目倉庫的 issues 中搜索答案，尤其是知名項目，用的人很多，你遇到的 Bug 有可能別人也遇到過。

如果有解決方案呢可以直接照搬，哪怕沒有解決方案，你也可以試著聯(lián)系遇到類似 Bug 的同學，共同探索。

5. 追溯源碼

除了依賴沖突、內存溢出之類的技術上的 Bug，其實我們工作中更多地是修復業(yè)務邏輯上的 Bug。比如做一個支付功能，用戶 A 扣了錢，但是沒有任何反應。

那么這種情況也別費功夫在網上搜了，因為每個人寫的業(yè)務代碼都不一樣，五花八門。不如自己從程序的入口開始，用 Debug 打些斷點、打印一些變量信息，一行一行慢慢調試就好了。

如果你懷疑是某個依賴的類或方法出了問題，也可以直接點進去查看它的源碼和注釋。

尋求幫助

如果自己無法解決問題，我們就只能向他人求助了。

提問技巧

提問也是有技巧的，想要更快、更準確地獲得答案，就要把你的問題、場景、前因后果、關鍵信息都提供清楚，還可以利用 PasteBin ?之類的工具分享代碼，讓別人更好讀懂。

像我每天都會收到上百條私信提問，其中很多同學連自己要問什么都描述不清楚，比如：我網站為啥無法訪問了？

這種問題我怎么幫你解決呢？這不是耽誤彼此的時間么？

所以我建議大家去閱讀《提問的智慧》這本免費小書，教你成為一個有智慧的提問者。

地址：https://github.com/tvvocold/How-To-Ask-Questions-The-Smart-Way

途徑

想好問什么之后，找誰問呢？

首先是兩大平臺：國內的 CSDN 相對適合初學者；國外的 Stack Overflow ，更活躍、解答人數(shù)會更多。

如果是開源項目，可以考慮在 GitHub 項目倉庫下自己提一個新的 Issues ，艾特團隊官方人員去解決。

如果你用了別人提供的類庫和服務，可以在官方文檔中找到項目的維護者，聯(lián)系他們并反饋。

此外，你也可以加一些專業(yè)人員的好友、加些編程交流小隊之類的抱團取暖，都是不錯的。

最后，如果以上方法都解決不了 Bug，那不妨試一試：重啟 ！

重啟大法好，Bug 逃不了。重啟還不行，那就卸載重裝~

以上就是本期分享，我是魚皮，求個 點贊 ，這將是我持續(xù)創(chuàng)作的最大動力，謝謝 ??