写在前面，2021年了，看到有人陆续看到这篇文章，点赞收藏。希望这篇文章能帮到你，不过都2021年了，现在在vscode上调试node应用变得更容易了。直接在package.json上，就可以debug模式启动npmscript，不需要下面的复杂操作。到这里已经9102年了，你的nodejs应用还在用控制台调试吗？从开始使用webstorm内置的debug功能，到使用node-inspector库进行调试摆脱webstorm的笨重，再到nodejs内置的debugger模块也可以帮助调试我们的应用。目前个人日常开发使用vscode，本文主要介绍vscode平台的debugger调试功能。vscode本身内置了对nodejs的调试支持。此外，还有许多调试扩展可供安装和使用。可以点击调试菜单->安装调试插件，会自动进入插件下载页面，过滤出调试器类型的插件，按下载量排序。不仅支持nodejs/js调试，像C/C++、python、go等都有相应的调试器插件，一般来说下载的越多越靠谱。而我们主要是为了调试nodejs应用，不需要额外下载插件。快速调试当前文件，在vscode中调试当前打开的文件非常简单，只需要按下快捷键F5或者按下编辑器左侧调试面板上的开始按钮，然后选择调试类型。注意：只有下载了对应的调试插件才会显示出来可供选择，比如只有安装了C++调试扩展插件，这里才会出现C++选项。启动后，就可以调试当前文件了。调试界面有几个模块的内容，可以看到断点、调用堆栈、脚本加载状态、调试控制台等。注意在调试控制台下，vscode在调试时执行的命令实际上是使用的原生调试器模块节点。新的调试配置虽然可以很方便的调试当前文件，但是往往不能满足我们的调试需求。因为我们需要大多数被调试的进程都需要特殊的从给定的命令开始，例如构建命令、测试命令或后端应用程序的启动命令。正如您在上面看到的，调试期间执行的命令只是简单地用节点运行当前文件并带上调试标志（--inspect-brk）。这时候我们需要单独配置具体的调试目标。进入编辑器面板左侧菜单，进入调试面板，然后点击新建添加配置，选择对应的调试类型。这里可以直接选择节点。之后vscode会帮我们在打开项目的路径下添加一个.vscode/launch.json文件，文件中已经添加了最基本的配置。{//使用IntelliSense了解相关属性//悬停以查看现有属性的描述。//有关更多信息，请访问：https://go.microsoft.com/fwlink/?linkid=830387"version":"0.2.0","configurations":[{"type":"node","request":"launch","name":"LaunchProgram","program":"${file}"}]}配置数组中的每个对象都是一个单独的调试配置，其中type、request、name是必填参数。type：debug操作类型，比如node/go/c/c++....request：launch/attach，下面都会解释name：用来区分每一个除了这三个参数，这个配置的其余参数都是可选的参数。还有许多剩余的可配置参数及其相应的可选值。可以阅读文档（debugging#launchjson-attributes）查看具体参数的含义。使用^（control）+space（空格）快捷键可以调出代码提示，也可以看到相应的说明。让我们简单看一下默认的基本配置。注意：vscode会根据当前打开的项目给出最合适的配置，比如读取package.json中的scripts字段并配置，所以默认的配置不一定相同。{"type":"node","request":"launch","name":"LaunchProgram","program":"${file}"}其中program参数为可执行命令或绝对路径一个文件，可以理解为程序启动命令。${file}占位符的意思是编辑器当前焦点所在的文件。所以在使用上面的配置开始调试的时候，效果和我们上面说的当前文件的调试是一样的。我举一个我平时使用比较频繁的场景的例子。它是一个npm模块命令提供的程序的启动命令。启动测试进程：Jest/Mocha/Ava启动构建进程：Webpack/Parcel启动后端进程：Sails/Meteor以vue-cli@3.x生成构建配置为例，一般对于更复杂的构建配置，我们需要检查cli生成的webpack配置是否正确。很多时候，如果生成的构建配置不符合我们的预期，而且我们一眼看不出问题所在，我们可以调试生成配置的过程。根据vue-cli文档#Review项目的-webpack-configuration，我们可以运行vue-cli-serviceinspect来查看我们的webpack配置。而vue-cli-service是由开发依赖A命令中的@vue/cli-service包提供的，具体存放路径为node_modules/.bin/vue-cli-service。这个时候我们可以这样配置/node_modules/.bin/vue-cli-service","args":["inspect"],"env":{"VUE_CLI_SERVICE_CONFIG_PATH":"${workspaceFolder}/build/vue.config.js"},"cwd":"${workspaceFolder}"}简单说明一下上面的配置，启动命令是当前工作项目目录下的node_modules/.bin(${workspaceFolder})/vue-cli-service。启动参数（args）为inspect.env配置node环境变量（process.env），指定VUE_CLI_SERVICE_CONFIG_PATH为当前工作项目目录（${workspaceFolder}）下的build/vue.config。js.cwd可以指定在某个文件夹执行启动命令。使用上述配置运行时，您可以观察调试控制台的输出。/usr/local/bin/node--inspect-brk=31449node_modules/.bin/vue-cli-serviceinspect然后可以调试生成配置的过程。request:launch/attach因为调试配置居中的可选参数太多，一一分析意义不大。另外还有很多参数我没有实际使用过，解释可能会有偏差，这里就不大惊小怪了，有需要的可以直接看官方文档（调试）这里主要说说需要的参数request，它有两个可选值，launch（开始）和attach（附加）。它们分别代表了vscode目前支持的两种调试模式，对应着两种工作流程。回到我们最熟悉的调试工具——chromedevtools，如果是我们日常调试网页的工作流程，对应的是vscode的debug模式，也就是attach模式。因为当我们打开devtools的时候，浏览器已经在运行了，打开devtools只是简单的把调试工具附加到浏览器上。vscode中的attach模式也是一样的。我们可以先以debug模式运行程序，然后将vscode的调试器通过attach连接到运行的程序上。而launch可以理解为vscode帮助我们以debug模式运行程序，自动将vscode的调试器附加到运行进程中。相关文档/延伸阅读https://code.visualstudio.com/docs/editor/debugginghttps://code.visualstudio.com/docs/nodejs/nodejs-debugginghttps://github.com/microsoft/vscode-recipeshttps://github.com/search?q=vscode+recipe
