寫程式碼時，通常要耗費大量的時間去排查bug產生的原因，如何快速的定位bug，在很大程度上決定了你的開發效率。下面是我的一些經驗分享。
提高編碼質量
在一個專案足夠簡單時，往往不會意識到編碼規範和程式碼質量的重要性。當專案大到需要多人協作或是接收別人的程式碼時，你就會意識到，編碼規範的統一、專案結構的設計、程式碼的易讀性和規範的註釋是多麼重要。
提高編碼質量不僅僅可以幫你快速的定位到bug，更能有效的減少bug數量。糟糕的程式碼就像堆在一起的雜物，而高質量的程式碼就像是分門別類的收納箱，在找東西時 ，哪個效率更高是顯而易見的。
當然，提高編碼質量不是一蹴而就的，需要有紮實的基礎知識，良好的編碼規範，以及日積月累的犯錯經驗。之後可以專門寫一篇文章，來介紹如何編寫高質量的程式碼。
閱讀報錯資訊
如果瀏覽器有輸出錯誤資訊，那麼根據錯誤資訊，我們就能大致判斷出錯誤型別以及可能出錯的原因。
比如:
- 根據如下報錯資訊，我們看到，程式碼在執行時，試圖去訪問某一物件的
attr屬性，而該物件並沒有被定義。這時候，我們只要在出錯的頁面去檢索關鍵詞attr，輸出attr所依賴的物件，就知道錯誤出在哪兒了
Uncaught TypeError: Cannot read property 'attr' of undefined
複製程式碼- map是陣列才有的方法，這裡可以預見的是，a並不是一個陣列，結果就是 a 沒有達到我們預期的格式
Uncaught TypeError: a.map is not a function
複製程式碼- js程式碼格式錯誤，通常ESLint會輸出報錯，檢查一下引號、逗號、小括號、大括號是否寫完整
Uncaught SyntaxError: Invalid or unexpected token
複製程式碼-
有時候，即便是看懂了報錯資訊，也不清楚自己的程式碼到底出了什麼問題。你可以把報錯資訊複製下來，去stackoverflow，segmentfault等專業問答網站去檢索一下，如果找到不到合理的答案，還可以去google或百度去搜。要相信，總有人會和你遇到過類似的問題。
善用console
有時候，程式碼不能以期望的方式執行，但又沒有輸出任何有效的錯誤資訊，我們可以使用console方法，將必要的資訊列印出來。
如何使用？
比如，但我們點選提交按鈕時，並沒有發起提交請求。這時，我們要檢視原始碼，找出從點選提交按鈕一直到發起請求中間，都執行了哪些步驟。並將關鍵步驟處的關鍵資訊輸出，比如if else的判斷條件、被遍歷的陣列和物件，以及可能中斷執行的return語句。
注意事項
在使用console輸出時，建議帶上關鍵詞，且不建議使用無意義的數字、字母等：
// good
console.log('attrValue', this.attrValue)
console.log('getModule方法的判斷條件', isShow)
// bad
console.log(666, this.attrValue)
console.log(isShow)
複製程式碼另外，在錯誤排除後，建議刪除不再使用的console除錯程式碼，避免在查詢其他錯誤時，造成不必要的干擾。
排除法
這個方法之前明明是正常的，我並沒有改動它，只是在其他地方加了一些程式碼，它就不正常了。
怎麼辦？假使頁面中一共有abcd五個方法，我們逐次註釋掉a, b , c , d，每註釋掉一個就執行一次程式碼，如果在註釋掉d以後，程式碼執行正常了，那麼問題就出在d身上。
剝離法
如果頁面的程式碼量很大，用排除法效率可能會很低，這時候我們可以試試剝離法。
同樣一個方法（元件），在A頁面執行沒有問題，放到B頁面就不行。這時候，可以建一個新的頁面，裡面只放這一個元件，然後執行，如果沒有異常，首先可以排除，不是這個元件的問題。接下來，把B頁面可能對該方法（元件）造成影響的條件，逐次新增進來，看看到底是哪個條件造成了異常。
線上故障排除
有時候線上程式碼出了故障，而本地又無法重現，由於線上程式碼不能使用console，並且上線程式碼都經過了壓縮混淆，導致很難除錯。
這時候可以試試sourceMap，在webpack的配置檔案中開啟sourceMap，在打包的時候會生成對應的.map檔案。然後將打包過的檔案整體上傳到伺服器，這樣除錯線上程式碼時，除了壓縮混淆過的程式碼，還會有一份原始程式碼，方便打斷點和閱讀程式碼。
不過這樣做也會有一些缺點，一是打包時間會變長，二是將原生程式碼暴露出去。所以，平時建議關閉sourceMap功能，只有在修復無法在本地重現的線上bug時再使用。而且，在修復完畢後，重新打一個沒有sourceMap的包，上傳到伺服器，避免原生程式碼洩露。