我觉得调试很多人应该都是做过的，以我为例，大一学 C 语言的时候我特喜欢调试，别人的做题做不出来我让他在 codeBlock 上调试一下就行了，其实这是因为那时候写的 C 语言就几行代码，文件结构简单，当然很好调试，后面慢慢接触的项目越来越复杂，刚开始创一个 vue 项目要等几分钟，很多项目代码混淆，乱作一堆，调试也只能去用console.log这种输出控制台的方式调试，后面通过慢慢学习，发现在 vue 项目里面还可以有很多种方式去调试，调试方法如下
前排提示，文章调试环境均为 Chrome 浏览器
源码中加 debugger
这种方式是之前看文章用到的，并不是我目前主力使用的方法，但是可以作为一个引子先介绍一下
注意，这种方式需要提前打开控制台(F12)
这是一种在源码中加入断点的方式去打印，使用方法也很简单，就是需要调试的地方去加上一个 debugger，然后运行代码就可以去使用了，具体效果可以看下面的 GIF
像这种动态的，用户类的操作可以很方便的操作
小结
优点
- webpack, vue-cli, vite 等目前使用较多的 vue 项目开发和构建工具都可以使用，只需在源码中打断点，不用担心代码混淆，无法定位 bug 位置
- 打完断点后，可以使用逐行调试，跳转到下一个断点等 Chrome devtools(就是 F12 控制台)提供的调试工具，对于 bug 出现在复杂逻辑的位置处可以更进一步解决和理清 bug
缺点
- 需要在源码中写
debugger, 用完了要删掉，和console.log()一样
直接在 Chrome devtools 上调试
这个方法可以帮助我们去解决刚才 debugger 写断点需要删除的缺点，直接在 Chrome devtools 的 Source 处打断点，什么？你不知道什么是 Chrome devtools？我来教你（绝对不是因为我想水字）
跟着上面图片做准没错
至于调试实操，还是用刚才熟悉的位置，打上断点，执行操作，效果请看下面的 GIF 图
注意小细节，注释掉 debugger 的位置，我们直接在 Chrome 浏览器中手动加上断点，不用在源码中写 debugger, 浏览器随开随用，非常人性化，非常好用
可能有用过 chrome devtools 的家人们想要问了，你这个 info.vue?fc24 的奇奇怪怪的文件名是什么鬼，我用 vue 的时候都找不到我原来代码喔，都是一些混淆的代码喔，其实这个也没错，因为 webpack 这种开发构建工具在给我们前端提供工程化的同时还帮我们微操了好一些（没错 webpack 是微操大师），如果你不懂 webpack 的原理的话可能调试比较困难（说实话我也不是很懂 webpack），导致我们找源文件的时候就只看到了下面这些
找到源文件
看到上面的图不要傻掉，其实真正的源文件在这里
然后看一下，真正的源文件目录结构，注意，有小细节，存在一些不同
注意这里还是要将就一下实操，因为你的目录结构很有可能和我的不同，导致截图给你的冲击力不是很大，我第一次找到 vue-cli 启动后浏览器的源码位置后还是有点激动的，至于为什么是在 webpack://./ 位置和 webpack 自己的原理有关，这里不多讲，注意，截图来源于 vue-cli 启动的项目
还有一个问题是，为什么有 info.vue?xxxx 这么多文件呢？(info.vue 是本篇文章调试的 vue 文件), 我大概看了一下里面的内容，是一些创建 DOM, render 的一写函数，所以我推测是 vue-loader 去分析源文件产生的一些附加的文件，这里也科普一下 loader, webpack 一开始是只处理 JS 的，像 vue, css 这种无法识别，需要加一个 loader 去分析，然后转化为 webpack 认识的代码，可以理解为中间解析器，那么这个目录结构上来看应该是 vue-loader 对源文件进行了一个解析后拆分
下面是一张 info.vue?xxxx 相关的图
快速找到源文件
这算是我偶然间发现的一个小技巧，能够快速找到需要调试的 vue 文件，就是利用 Chrome devtools 的 Open file, 就是在下面这个位置
不过不知道也没关系，因为它有一个快捷键 Ctrl + P, 调出来对话框后，输入文件名就可以快速找到需要调试的文件，不需要去 webpack 里面一个个的点开文件夹，如果你的目录结构很复杂的话，找到你需要调试的文件也需要好一段时间，所以用快捷键何乐而不为呢？实操如下
有些家人们可能发现了你怎么能够直接找到源文件的呢？是不是提前看过？其实不是，是因为输入关键字.vue 后，最下面那个文件就是保存 <scirpt></script> 相关的文件，就是 JS 相关的，通常这部分内容和我们源文件中的是一模一样，因为本身就能够被 webpack 识别，不需要转译，而且这部分内容也往往是我们需要调试的部分，JS 源文件位置如下
小结
优点
- 具有上面
debugger方法全部的优点，但是又解决它的缺点
缺点
- Chrome 直接打断点调试也有自己的缺点，比如断点不明确的问题，可能打一个出现五六个奇怪的位置，建议和
debugger互补使用
