相信絕大部分的前端是使用Chrome進行開發的，一方面Chrome瀏覽器確實做得好，更重要的一方面是因為Chrome有一個無法匹敵的調試工具。用好這個調試工具可以提高編程效率，幫助快速地定位問題。

01?打印

（1）console.table

最常用的打印是console.log，console.log有時候打印一些復雜的數據結構顯得有點吃力，如打印一個元素是object的數組：

為了查看每個數組的元素，必須得一個個展開，就顯得有點麻煩了，其實可以用console.table：

瞬間就變得非常清爽，同時console.table還支持打印對象屬性，如下的Student對象，有name和score兩個屬性：

（2）console.dir

console.log是側重于字符串化的打印，而console.dir能遞歸打印對象的所有屬性，如下打印一個dom結點：

console.log把它的html打印出來了，而console.dir把它的所有屬性打印出來，方便進行檢查。

（3）打印帶樣式

經常會看到有些網站會在控制臺打印一些提示語，并且這些提示語還帶樣式，這個是用%c加上的樣式：

02?檢查沒有用的CSS/JS

Chrome 49新增了一個功能，能夠檢查頁面上的CSS/JS沒有用到的比例，如下打開devtools的Coverage標簽欄，然后點記錄按鈕，刷新頁面，頁面加載完之后，點擊停止。就會顯示頁面用到和沒用的CSS/JS占比。沒有用到的用紅色表示，用到的用綠色表示：

可以看到第二個CSS文件有大部份是沒用到的，JS也有很大的比例沒有用到。在上面中間的窗口會把具體沒使用到的代碼標紅，就能知道具體哪些代碼沒有被用到。可以看到，CSS有一半沒有用到，因為有一些是小屏的響應式CSS，大屏沒用到。另一些是common-chunk提出來的，所以可以考慮把大小屏的CSS分開（但是不適合于內聯Style），如下用媒體查詢去加載不同的CSS：

<link rel="stylesheet" href="large.css" media="screen and (min-width:500px)">

JS也是因為require了比較大的公有模塊導致的，這些模塊比較大，但是只使用了其中小一部分功能，可考慮把大模塊拆細，但是?；毧赡軙黾訌碗s度，所以要權衡一下。

這些功能可以用Chrome Canary嘗鮮版的使用。

03?截全屏的功能

除了Corverage之外，Chrome 49還新增了截全屏的功能：

就不用去裝一個第三方的插件。

04?debugger

可以在代碼里面寫一句debugger，一旦運行到dubugger就會自動卡在那里進入調試模式，使用這個有兩個好處，一個是不用手動去展開文件找到對應的位置，因為現在很多人都用第三方的打包，導致跑的代碼和本地的代碼行數不能保持一致，所以需要去搜索相應地代碼，比較麻煩。另外一個好處是：當代碼是一個很大的循環的時候，并且在特定的情況下代碼會掛，由于要循環好多次，所以有時候不可能在循環里面打個斷點，然后不斷地跳到下一個斷點直到出現問題。所以這時候怎么辦呢？可以用條件結合debugger。如下代碼：

var scores = [90,70,58,60, ...]; var newScores = [88, 55, 60, ...];for(var i = 0; i < scores.length; i++){ ? ?for(var j = 0; j < newScores.length; j++){ ? ? ? ?if(scores[i] !== newScores[j]){scores.push(newScores[j]);}} }

發生了死循環，怎么定位在哪里出了問題呢？方法一在循環里面打個斷點，一次次執行分析，直到發現問題，方法一有時候挺好用的，可能很快就可以發現問題了。方法二，發生死循環了肯定是i不斷得在變大，但是為什么i不會停止變大，可以加個條件，當達到那個條件的時候進入斷點：

? ? ?if(i > 1000000){debugger}

如上面第7行，當i大于1000000時進入斷點，這個時候檢查一下，發現scores已經變成了一個很大的array了：

所以可以進一步發現問題。這樣就解決了大循環里面打斷點調試的問題。

使用debugger還有一個小技巧——可以解決一個檢查頁面元素的問題。如下圖所示，當hover到那個綠色的標簽時，會出來個詳情框：

現在我要檢查這個詳情框，但是我一檢查，鼠標離開了，那個框也消失了，導致檢查不了了，因為觸發了mouseout事件，那怎么辦呢？假設這個框是css的hover控制的，那么可以用控制臺的偽類窗口，在:hover那里打個勾，就有hover的效果：

但是這個不是用css的hover實現的，所以沒辦法用這個。這里有一個小技巧，就是用debugger讓頁面卡住了，mouseout事件的響應函數就不會執行了。如下，先在左邊的控制臺點一下進入編輯模式，然后把鼠標挪到左邊的頁面的標簽，讓那個框出來，然后再在控制臺輸入debugger回車，這個時候頁面就卡住了，接著就可以愉快地進行檢查了，如下圖所示：

05?IOS真機模擬

這個雖然和Chrome沒關系，但是也可以提一下，Mac的XCode可以開一個ios系統，操作如下圖所示，然后可以用Mac的Safari接連這個ios里面的Safari進行檢查：

如下例子調試iPhone的Safari：

上面右圖彈了一個原生的下拉，因為它是真的ios系統，這個的好處就在于不用老是連真機調試，適合于有Mac但是沒有iPhone的同學，缺點是沒辦法和真機100%一樣，例如它不彈鍵盤，它的輸入是用電腦鍵盤的輸入。不過它是100%的ios系統，另外需要裝一個很大的XCode。

06?用console.trace追蹤函數調用

現在遇到了一個問題，就是點擊X按鈕的時候重復發了兩個請求，如下下圖的紅框：

當上一次請求還沒完成又要發一個新的請求的時候，代碼里面會把上一次請求abort掉，所以會看到上一個變紅了：

但是這樣還是會有問題，所以要看一下究竟是在哪里觸發了兩次請求。由于請求會走一個通用的發請求的接口，所以可以在那里追蹤一下：

ajax: function(curPage){console.trace("search.js ajax");//other code }

然后控制臺就打印了兩次trace：

分別點開這兩次的代碼，就會發現，兩次觸發分別是：一次是X的click事件調的搜索，另外一次是map的zoom_changed觸發的搜索，知道了調用的地方就好辦了，就可以做進一步分析，然后去掉其中一個。

另外一個看函數調用棧的地方是在右邊的窗口：

調用棧最多只打印5個，有時候可能會不太夠。

07?查看某個函數綁的事件

控制臺Elements的下面有個Event Listeners，點最后面那個可以看到和它最相關的事件

其次，用好快捷鍵可以事半功倍，常用的快捷鍵：

F10 下一步

F8 跳到下一個斷點

command/ctrl + ; ? ? ? ? ? ?step into進入函數執行

shift + command/ctrl + ; step out跳出當前函數

一個實例——研究一下鼠標hover的時候它的邊界是怎么畫出來的：

首先定位到mouseover事件，因為它必定是mouseover觸發的：

一打開發現代碼是壓縮的：

壓縮的代碼可以點左下角的大括號，進行美化：

然后再用快捷鍵一步步的step over/step into，如果你不用快捷鍵老是一個個去點那個調試的按鈕還是挺麻煩的。如果不小心過了，就重新來一遍。最后會找到在這個函數里面畫的邊界：

08?Open in Sources Pannel

在sources pannel面板如果要查看某個源文件的時候，需要一步步展開文件夾，這樣比較麻煩，而在network面板里面可以用各種篩選，但是在network里面是不能打斷點的，這個時候可以用右鍵，然后點擊Open in Sources Pannel的功能：

就會在sources面板打印相應的文件，然后可以在sources里面進行調試了。

09?模擬斷網做一些出錯處理

devtools還支持模擬網絡情況，例如可以模擬斷網的情況，突然掛掉了會怎么樣，然后相應的做一些出錯處理：

如上圖出錯的時候給一個提示文案，同時恢復upload按鈕，就可以讓用戶再重新上傳。

10?研究重繪

devtools有一個Renders可以用來研究重繪，如下圖右下角，把面板里面的勾都打上：

然后點擊左邊的頁面的菜單按鈕研究重排的情況。右上角黑色的框會顯示當前的幀率。左邊變藍的區域表示需要進行重繪，由于要彈一個蒙層，所以頁面可視區域進行重繪了。同時可以看到當前幀率是59，而且整一個過程幀率基本保持在55以上，因為這個是用transform做的動畫，所以幀率比較高。再來看一個用postion做的動畫：

可以看到幀率跌到了45，并且有相當一小段時間幀率是在50以下，所以用postion做的動畫流暢度沒有transform的好。

11?用timeline看執行時間

如下圖所示，可以查看很多有用的信息：

這個我在《Effective前端6：避免頁面卡頓》有詳細的介紹。

12?檢查內存泄漏

基本上只要存在一個引用就不會進行GC回收，有些DOM節點沒有append到DOM，但是存在引用指向它，它就是一個分離的DOM結點，這個時候發生了DOM內存泄漏，如下面的代碼：

var detached = null; button.on(“click”, function(){detached = document.createElement(“div”); })

由于閉包里面有一個變量指向一個分離的DOM結點，所以創建的那個變量指向的內存空間不會被釋放掉。這個時候可以拍一張內存堆的快照，Chrome會幫你把這些分離DOM結點用黃色標出來。

先切到Profile標簽，選中Take Heap Snapshot選項，然后點擊Take Snapshot按鈕：

然后就會把當前內存的使用情況顯示出來：

在搜索框里搜一下detached，出來的結果里面紅色的表示已經分離且沒有引用，而黃色表示已經分離且有引用，所以重點是看這些黃色的。展開其中一個分析一下，可以看到這個HTMLDivElement有一個ImageShower里的$imgContainers指向它，所以導致它的內存空間不能被釋放。具體看下代碼可以看到這是DOM已經刪了，但是圖片懶惰加載里面沒有清掉引用。所以解決辦法是當刪掉DOM節點時，把那個ImageShower里面的變量置為null，或者把整個實例對象置為null。

13?查看內存消耗

為了查看某個操作的內存消耗情況，可以用Record Allocation的功能記錄某個操作內存的分配情況。

點了start按鈕之后，進行一個操作，例如彈一個框，然后點擊停止記錄的圖標，就會出來使用情況的分析，如下圖所示：

點開最上面的Object，可以看到這個Object數組開銷了553K的內存（下圖倒數第二列第一行）：

展開其中一個Object，可以看到它是一個jQuery對象，每一個消耗了88Kb：

而總的內存可以用Chrome的任務管理器查看：

可以看到當前頁面消耗了193Mb的內存。所以如果當你覺得頁面的內存比較大的時候，或者重復某個操作之后頁面的內存不斷增大，就可以用這種方法分析一下。

14?垃圾回收

垃圾回收可以在timeline里面查看，如下圖所示：

藍線那里JS Heap驟降，說明進行了一次垃圾回收，如果發生得比較頻繁的話，可能會有問題。

15?查看連接時間

如下圖所示：DNS解析花了254ms，建立tcp連接花了1.98s，建立https連接花了1.69s，從建立完連接到接收到第一個字節的數據(TTFB，Time To First Byte)等了4.3s，下載時間花了306ms（基于某次實驗）。

另外圖片的優先級會低于CSS/JS資源，并且同一個域最多只能同時加載6個資源，所以會有排隊和等待時間，如下圖所示：

本文分析了一些devtools的一些比較好用的功能，結合自己的項目經驗做了些實際的例子說明，希望對大家有幫助。

總結

以上是生活随笔為你收集整理的如何用好 Chrome devtools的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。