我所知道的JS调试
前言
任何一门语言都有对应的调试方法，也有对应的调试工具，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，就可以进入调试状态，打上断点，同样可以查看本地变量/堆栈等等信息。如下图：
