前言
任何一門語言都有對應的調試方法，也有對應的調試工具，JavaScript當然也不例外。最常用的莫過於瀏覽器這個調試工具了。而今天我們要講的對於這個基礎調試就不細說，我會將目前所有調試javascript(nodejs)的方法以及工具(主要是VS Code)介紹一下，然后順便講解一下webpack的sourcemap功能。
1 前置條件
- Chrome: 55+
- Nodejs: 6.3+
我當前使用的Nodejs(7.10)和Chome(Version 59.0.3071.104)
該文章配合了一個demo：
2 如何利用sourceMap來調試或者定位我們的錯誤
現代的網頁越來越復雜，加上有babel這類的工具來對我們寫的Js代碼轉譯，然后有uglify這類工具進行壓縮，最后我們看到的代碼與原先的代碼相差將會很大，單純靠打印調試是效率極低的，於是這個時候sourceMap這個功能便應運而生。
在這里我們結合最火爆的打包工具webpack來說說如果利用webpack的sourcemap功能來調試以及定位錯誤的位置。
首先使用chrome調試帶有sourcemap功能的js文件需要有下面的條件：
- chrome開啟支持
sourcemap的功能 - webpack配置
devtool參數
開啟chrome的sourcemap支持：
如果配置webpack但是沒有開啟支持，那么chrome的控制台將會是這樣的：
如果開啟支持但是沒有對應的sourcemap文件：
滿足以上兩個條件就可以：
在webpack的官網文檔中提供了10中方法，那么這10種方法有哪些區別，我們要如何更好地利用這些參數去調試呢？下面我們一一通過圖片來簡單地過一遍。
2.1 eval
該方法官方文檔標榜是效率最高的，它會使用eval執行每一個module，然后每個module后面都會跟着//@ sourceURL。如下圖：
配置如圖：
生成的文件如下圖：
官網文檔說該方法的最大缺點是不能准確地顯示行號，但下面的報錯圖是我截取的，貌似行號是正確的顯示的。不建議用於產品環境下。
2.2 eval-source-map
這個就是把eval的sourceURL換成了完整souremap信息的DataUrl，剛開始第一次編譯的時候是比較慢，但重新編譯的時候速度會大大地變快。其對應的行號可以正確顯示因為其是從原始代碼來做映射的。對應的配置和報錯圖如下：
報錯提示：
不建議用於產品環境下。
2.3 inline-source-map
為每一個文件添加sourcemap的DataUrl，注意這里的文件是打包前的每一個文件而不是最后打包出來的，同時這個DataUrl是包含一個文件完整souremap信息的`Base64 格式化后的字符串，而不是一個url。對應的配置文件：
錯誤的定位情況以及生成的文件如下：
不建議用於產品環境下。
2.4 cheap-eval-source-map
類似於eval-source-map，但是取名為cheap是因為它沒有列映射，只有行映射。對應的webpack配置如圖：
其生成的文件如下：
報錯的定位情況：
不建議用於產品環境下。
2.5 cheap-module-eval-source-map
類似於cheap-eval-source-map,但是官網稱這個選項可以更好地處理映射。對應的配置如下：
錯誤的定位情況如下：
不建議用於產品環境下。
2.6 source-map
該選項會生成一個sourcemap文件，然后在bundle文件中添加一個引用聲明，這樣開發工具可以知道在哪里找到sourcemap文件，對應的配置如下：
生成的sourcemap文件大致如下：
錯誤定位情況如下：
2.7 hidden-source-map
和source-map一樣，但是不會添加引用聲明到bundle文件中。如果你只想要讓sourcemap從錯誤報告中映射錯誤堆棧追溯，但是不想暴露你的sourcemap文件給開發者工具的話，這種方式很適合你的。對應的配置如下：
錯誤定位情況：
2.8 cheap-source-map
類似於source-map，但是沒有列映射。對應的配置如下：
錯誤定位情況：
bundle文件最后的注釋如下：
2.9 cheap-module-source-map
此種方法也沒有列映射，同時 loader 的 sourcemap 也被簡化為只包含對應行的。最終的sourcemap只有一份，它是webpack對 loader生成的sourcemap進行簡化，然后再次生成的。對應的配置如下：
錯誤定位情況：
2.10 nosources-source-map
該方法生成的sourcemap文件沒有sourcesContent字段，如下：
配置如下：
錯誤定位情況：
3 前端代碼debugger調試
如果我們在前端代碼中指定的位置打斷點，除了可以直接在控制台中直接打斷點，還可以在你的代碼中添加debugger關鍵詞來打斷點：
4 Nodejs的調試
Nodejs寫多了，就免不了調試，而最低級的console打印貌似滿足不了調試nodejs，於是我們就開始尋求新的調試方法，今天就給大家列舉兩種常用的調試工具。
首先我們需要開啟Nodejs調試狀態，只需要在啟動的文件使用--inspect即可，如下圖：
於是在終端會打印出下面的紅框中的重要的一行話：
Debugger listening on port 5859.
[1] Warning: This is an experimental feature and could change at any time. [1] To start debugging, open the following URL in Chrome: [1] chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:5859/39515fe7-3f4a-40b2-8b95-6196a2d22d73 眼尖的童鞋肯定會發現為什么你的打印中出現了兩次Debugger listening on port，那是因為我使用的Nodejs文件監控重啟包是piping，而這個包的一個最大的特點便是：
使用默認的設置的時候，那么將會啟動第二個實例，這個實例由第一個實例監控。Piping在第一個實例中故意人為的引發uncaughtException操作來避免繼續執行其他代碼，所以真正執行服務器代碼的是在第二個實例，這也就是我們應該使用第二個打印的原因。
4.1 Chrome調試Nodejs
基於上面的介紹，我們將第二個實例打印的調試地址粘貼復制到Chome地址欄中，即可打開調試窗口，然后在你想要打斷點的地方加上斷點即可：
4.2 VSCODE調試Nodejs
除了使用chome，你還可以使用VSCode這個神器。使用VScode調試得配置一下：
使用如下的調試配置：
{
// Use IntelliSense to learn about possible Node.js debug attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Attach to Process", "type": "node", "protocol": "inspector", "request": "attach", "address": "localhost", "port": 5859 } ] } 其中端口的配置記得和之前打印的調試端口一致，這里都是5859。
然后啟動你的Nodejs服務，接着按下F5，就可以進入調試狀態，打上斷點，同樣可以查看本地變量/堆棧等等信息。如下圖：
