我觉得断点调试是所有程序员的一门必备技能。不过据我的观察,身边不会断点调试的朋友还不少,可能大家都是一样的想法,我不能用 console.log 进行调试吗,非要用什么断点调试,花里胡哨。

其实一开始的我也是这么想的,直到我用上了断点调试才发现,这玩意是真的香。我认为断点调试应该归属于效率工具这一类别中,换而言之,你实在不会也不是不行,就是效率低下而已(其实这话已经很重了嗷!)。

最后说下,其实 VS Code 的调试相关的内容在 VS Code 官网已经写的很好了,但是中文互联网这块我却没有看见比较好的文章,因此

这篇文章是对 VS Code 官网中 Debugging 章节的翻译,作为我自己的留档。

文章并不是一板一眼的翻译,并且在有些地方做了一些补充,欢迎勘误。


原文链接:https://code.visualstudio.com/docs/editor/debugging#_launch-configurations 原文作者:VS Code

VS Code 的主要特点之一就是其对 debugging 的良好支持。VS Code 内置的 debugger 将有助于提升你在编辑,编译,debug 流程上的效率。
image.png

Debugger 插件

VS Code 使用 Node.js 运行时为内置的调试提供支持,VS Code 可以调试 JavaScript,TypeScript,或者其它任何可以被转换为 JavaScript 的语言。

对于调试其它语言或者运行时(包括,PHP, Ruby, Go, C#, Python, C++, PowerShell 以及 many others),请在 VS Code 的插件市场中查找 Debuggers 相关的插件,或者选择在顶级的运行菜单中安装额外的调试工具

下面是几个流行的插件:
image.png

开始 Debugging

下面的文档将会基于 VS Code 内置的 Node.js 调试器,不过大部分的概念和特性都可以用于其它的调试器。

在我们学习如何 gebugging 之前,我们可以先创建一个简单的 Node.js 应用程序。你可以按照 Node.js 攻略 去安装一个 Node.js 并且创建一个简单的 “Hello World” 程序(app.js)。当你准备好了一个简单的程序之后,这篇教程将会带你过一遍 VS Code 调试相关的功能。

译注: MacOS 安装 Node.js 环境我建议使用 nvm 等 Node 版本管理工具。 原因:「Bug Fix」macOS下npm全局安装的权限错误

运行界面

你可以在 VS Code 的侧边栏(Activity Bar)中点击 Run 图标来打开运行界面。除此之外,你还可以使用快捷键⇧⌘D 打开
image.png
运行界面将会显示所有有关于运行和调试相关的信息,并且带有一个控制调试命令和配置设置的顶栏(top bar)
image.png
如果在运行和调试的时候没有进行配置(没有创建 launch.json),VS Code 将会显示如下页面:
image.png

运行菜单

顶级的运行菜单(The top-level Run menu)中有很多常见的运行命令和调试命令:
image.png

启动配置(Launch configurations)

在 VS Code 中,我们在 Debug 的起始界面选择 Run and Debug 或者按下 F5 来运行或者调试某一个程序,并且 VS Code 将会尝试运行你当前正在活动的文件(currently active file)。

然而,在大多数的调试场景中,创建一个启动配置文件更加高效。因为启动配置文件允许你配置和保存调试时的一些初始化细节。VS Code 将调试相关的配置信息存储在 launch.json 文件中,该文件位于 workspace (项目根目录)中一个名为 .vscode 的文件夹,或者在你的 user settings 或者 workspace settings

点击 Run 起始界面中的 create a launch.json file 链接来创建 launch.json 文件。
image.png
VS Code 将会尝试自动指定你的调试环境,如果失败了,你将会手动选择调试环境。
image.png
这里是为Node.js调试生成的启动配置。

译注:我自己试了下,VS Code 生成的配置和文档的略有差别,不过并不影响你学习。

  1. {
  2. "version": "0.2.0",
  3. "configurations": [
  4. {
  5. "type": "node",
  6. "request": "launch",
  7. "name": "Launch Program",
  8. "skipFiles": ["<node_internals>/**"],
  9. "program": "${workspaceFolder}\\app.js"
  10. }
  11. ]
  12. }

如果你回到文件管理界面(File Explorer view,⇧⌘E)你将会看到 VS Code 已经在你的 workspace 中创建了一个 .vscode 文件夹,并且添加了一个 launch.json 文件。
image.png

注意:你可以调试单一个的应用程序,即使你没有在 VS Code 中打开文件夹。不过这将不能管理启动配置以及设置更高级的调试。如果没有一个文件可以打开,VS Code 的底部的状态栏将会变为紫色。

注意,启动配置中可用的属性因 debugger 而异。你可以使用智能建议( IntelliSense suggestions ^Space)去找到特定的 debugger 上存在那些属性。悬浮(hover)在属性名之上也适用于所有的属性。

请不要假设一个属性在一个 debugger 中生效,该属性就会自动的对其它的 debugger 生效。如果你看到有绿色的波浪线出现在你的启动配置中,请将鼠标悬停之上,了解其问题所在,并在启动调试会话之前修复这些问题。
image.png
检查所有自动生成的值,并且确保它们都将作用于你的项目和 debugging 环境。

启动配置 VS 附加配置(Launch versus attach configurations)

在 VS Code 中,有两种核心的调试模式,发射和附加(Launch and Attach),它们处理的两种不同的工作流程和开发人员的环节。根据你的工作流程,VS Code 很难去知道哪一种类型的配置是适合你的项目的。

如果你有着浏览器开发者工具的使用背景,你可能并不习惯“lunching from your tool”,因为你的浏览器实例已经打开了。当你打开 DevTools 时,你只是把 DevTools 附加在了你打开的浏览器标签页。另一种情况,如果你是来自于服务端或者桌面端开发背景,让你的编辑器帮你启动进程是一件很正常的事情,并且你的编辑器将会自动为这个新启动的进程添加 debugger 。

解释启动和附加的最好的方式是,将启动配置当成一个方法(配方),也即通过什么方法在 VS Code 附加在你的程序之前使用调试模式启动你的程序。而可以将附加配置看成通过什么方法将 VS Code 的 debugger 链接到已经运行的应用程序或者进程上。

上面这段话的原文:

The best way to explain the difference between launch and attach is to think of a launch configuration as a recipe for how to start your app in debug mode before VS Code attaches to it, while an attach configuration is a recipe for how to connect VS Code’s debugger to an app or process that’s already running.

译注: 这里概念不好太理解,这里我给出自己的理解:启动配置需要关心的流程是:启动前的环境配置 -> 启动 debugger,而附加配置需要关心的流程是:已经存在一个正在运行的程序 -> 开启 debugger 接管该应用程序进行调试。

VS Code 的调试器通常支持在调试模式中启动程序或者在调试模式中附加在一个已经在运行的项目。根据对应的请求(attach 或者 launch),需要不同的属性,并且 VS Code 的 launch.json 验证和建议将会帮助解决这个问题。

添加一个新的配置

可以使用下面的几种方式向一个存在的 launch.json 文件中添加新的配置。

  • 使用智能感知(IntelliSense)当你的指针位于配置信息数组之中时。
  • 点击 Add Configuration 按钮在配置信息数组开始处调用智能感知的代码片段
  • 在运行菜单中选择 Add Configuration 选项

add-config.gif
image.pngimage.png
VS Code 还支持复合启动配置(compound launch configrations),用于同时启动多个配置,更多的细节,请阅读这一 章节

为了开启调试会话,首先在运行界面(Run view)中的 Configuration 下拉框中选择一个名为 Launch Program 的配置。一旦你设置了你的启动配置,按下 F5 开启你的调试会话

或者,你可以通过 Command Palette(⇧⌘P)筛选出 Debug: Select and Start Debugging 或者输入 ‘debug’ 来运行你的配置,或者选择你想用进行调试的配置。

一旦调试会话启动,那么 DEBUG CONSOLE 面板将会出现并且显示调试的输出,并且底部的状态栏会改变颜色(橙色为默认的颜色):
image.png

除此之外,调试状态将会出现在底部的状态栏中,它将展示着当前活动的调试器的配置。通过选择调试状态,一个用户可以改变活动中的启动配置(change the active launch configuration)并且开启不需要打开运行界面
直接开启调试。
image.png

Debug actions

当调试会话启动,调试工具栏(Debug toolbar)将会出现在编辑器的顶部。
image.png

  • Continue / Pause F5
  • Step Over F10
  • Step Into F11
  • Step Out ⇧F11
  • Restart ⇧⌘F5
  • Stop ⇧F5

    译注:这里用英文我认为比中文更加直接

提示:可以通过设置 debug.toolBarLocation 去控制 debug toolbar 的位置。它默认是浮动的(floating),停靠(docked)在运行界面之上,或者隐藏。一个浮动的(floating)调试工具栏可以被水平的拖动,也可以向下拖动到编辑区。

运行模式(Run mode)

除了调试一个项目,VS Code 也支持运行一个项目。你可以使用 ^F5 来触发 Debug: Run (Start Without Debugging),并且使用当前选中的启动配置。有很多启动配置的属性也支持在运行模式(Run mode)中使用。当一个程序在运行的时候,VS Code 包含了一个调试会话,并且按下 Stop 按钮将会终止这个程序。

提示:Run action 始终都是有效的,但是并不是所有的调试器插件都支持 ‘Run’。在这种情况下,’Run’ 将会等同于 ‘Debug’。

断点(Breakpoints)

通过在当前行点击编辑器的页面边上的空白处(editor margin)或者使用 F9 来 toggled 断点。更精细的断点控制(enable/disable/reapply)可以在 Run view 的 BREAKPOINTS 部分完成。

  • 断点一般表现为 editor margin 上的实心红点。
  • Disabled 的断点是一个实心的灰点。
  • 当一个调试会话启动,不能在调试器上注册的断点会变成灰色的空心圆。如果在不支持实时编辑的 debug session 运行时编辑源代码,也可能发生同样的情况。

如果调试器支持中断不同类型的错误或异常,那么这些也会在 BREAKPOINTS view 中出现。

Reapply All Breakpoints 命令将会在它们原来的地方重新设置所有的断点。如果你的调试环境很 “懒”,在尚未执行的源代码中 “误放 “断点,这就很有帮助。
image.png
可选择的,通过开启 debug.showBreakpointsInOverviewRuler 使断点显示在编辑器的 overview ruler 中。
image.png

Logpoints

Logpoint 是 breakpoint 的一种变体,debugger 遇到 Logpoint 时并不会中断,而是在控制台打印出一些信息。Logpoints 在调试不能暂停或停止的生产服务器时,注入日志(injecting logging)将特别有用。

Logpoint 用一个菱形的图标表示。日志信息是一个纯文本,但是用花括号({})包括需要包含的表达式。
log-points.gif
就像普通的断点一样,Logpoints 可以被开启或者关闭,也可以被条件 和/或者 点击数(hit count)控制。

注意:VS Code 内置的 Node.js debugger 支持 Logpoints ,但是 Logpoints 也可以被其他的 debug extensions 实现。比如说,PythonJava 的插件就支持 Logpoints。

监控数据 Data inspection

可以在 Run view 的 VARIABLES section 查看变量,或者直接将鼠标悬浮到编辑器对应的源码之上。变量的值和表达式的值依赖于在 CALL STACK section 中选中的栈帧(stack frame)

译注:这里有点难懂,我的理解是,变量的值和表达是的值依赖于当前上下文环境。

image.png
变量的值可以通过变量上下文(variable’s context)菜单中的 Set Value action 修改。除此之外,你还可以使用 Copy Value action 去拷贝变量的值,或者使用 Copy as Expression action 复制一个表达式来获取变量。
image.png
变量和表达式也可以在 Run view 的 WATCH section 中被计算和观察。
image.png
当聚焦于 VARIABLES section 时,可以通过键盘输入(typing)的方式筛选出符合 typing 条件的变量名和值。
image.png

Launch.json 属性

VS Code 为 launch.json 提供了很多属性,这些属性将会帮助 debugger 适用于各种不同的调试场景。正如上面提到的,当你为 type 属性指定值的时候,你可以使用 IntelliSense(^Space)来查看可用的属性列表,
image.png
下面几个属性所有的 launch configuration 都强制拥有:

  • type - 该 launch configuration 要使用的 debugger 类型。每一个安装的 debug extension 都通过 type 引入。比如说:node 是引入内置的 Node debugger,而 php 和 go 将会使用 PHP 和 Go 的 extensions。
  • request - 该 launch configuration 的请求类型。现在支持 launch 和 attach 两种类型。
  • name - 一个便于阅读的名字,该名字将会显示在选择调试启动配置的下拉框中。

下面是一些可选的属性,且在所有的 launch configurations 都生效:

  • presentation - 在 presentation 对象中通过 order,group 和 hidden 字段,你可以在 Debug configuration 下拉框中排序,分组或者隐藏和显示对应的配置,以便于在 Debug 的时候快速选中。
  • preLaunchTask - 在开启一个 debug session 之前启动一个任务,将属性设置为 tasks.json(该文件位于 workspace 下的 .vscode 文件夹) 中指定的任务标签。或者设置为 ${defaultBuildTask} 去使用你的默认构建任务。
  • postDebugTask - 在 debug session 结束的时候启动任务,使用 tasks.json 中指定的任务名设置为该属性。
  • internalConsoleOptions - 该属性控制在 debugging session 活动期间,Debug Console 面板是否可出现。
  • debugServer - 只有 debug extension 作者需要使用:该属性允许你连接一个特殊的端口而不是启动 debug adapter。
  • serverReadyAction - 如果你想让调试中的程序向调试控制台或集成终端输出特定信息时,在网络浏览器中打开一个URL。细节请看 Automatically open a URI when debugging a server program

大部分 debuggers 支持下面这些属性:

  • program - 启动调试器时要运行的可执行程序或文件
  • args - 传递给 program 用于调试的参数
  • env - 环境变量(null 值可以用来作为一个 “undefine” 变量)
  • envFile - 存储有环境变量的 dotenv 文件的路径
  • cwd - 当前工作的路径,用于寻找依赖和其它文件
  • port - attaching 到一个运行中的进程的端口号
  • stopOnEntry - 当程序启动后立即打断
  • console - 使用那种类型的控制台(console),internalConsole,integratedTerminal 或者 externalTerminal

译者注:internalConsole 是 console 属性默认的值,该 internalConsole 不支持读取 program 的 input 数据。也就是说,类似于调试 Inquirer.js 这种库,你不能使用 internalConsole 作为 console 属性的值。

变量替换 Variable substitution

VS Code 提供了一些常用的路径和有用的值作为变量,并且允许这些变量在 launch.json 中替换字符串。这意味着你在 debug configurations 中不再需要使用绝对路径。比如:${workspaceFolder} 提供该 workspace 文件夹的根路径,${file} 代表着在编辑器中 active 的文件的路径,${env:Name} 指代环境变量中 “Name” 。你可以在 这里(variables reference) 看到所有的预定义变量,或者在 launch.json 中使用 IntellISense。

  1. {
  2. "type": "node",
  3. "request": "launch",
  4. "name": "Launch Program",
  5. "program": "${workspaceFolder}/app.js",
  6. "cwd": "${workspaceFolder}",
  7. "args": ["${env:USERNAME}"]
  8. }

译注:active 这个词的意思是活跃的,但我感觉不好翻译,图示给你看什么是 active image.png

技术文档中这种表示挺多的,active 就是指的是当前活动的窗口。

操作系统特定的属性

Launch.json 支持定义依赖于 debugger 所运行的操作系统的值(例如,要传递给程序的参数)。要做到这一点,在 launch.json 文件中放入一个平台特定的字面量,并在该字面量中指定相应的属性。

下面的例子中,传递了 “args” 给程序,并且在 Windows 平台上,“args” 是特殊的值:

  1. {
  2. "version": "0.2.0",
  3. "configurations": [
  4. {
  5. "type": "node",
  6. "request": "launch",
  7. "name": "Launch Program",
  8. "program": "${workspaceFolder}/node_modules/gulp/bin/gulpfile.js",
  9. "args": ["myFolder/path/app.js"],
  10. "windows": {
  11. "args": ["myFolder\\path\\app.js"]
  12. }
  13. }
  14. ]
  15. }

在 Windows 系统中 "windows" 字段有效,在 Linux 中则是 "linux",在 macOS 中则是 "osx"。
在指定操作系统作用域中定义的属性将会覆盖全局作用域中的属性。

请注意,type 属性不能位于特定平台(platform-specific)的字段里面,因为 type 属性直接决定了远程调试场景的平台,这将会导致循环依赖。

在下面的例子中,除了在 macOS 系统,调试程序始终会在入口处暂停(stops on entry)。

  1. {
  2. "version": "0.2.0",
  3. "configurations": [
  4. {
  5. "type": "node",
  6. "request": "launch",
  7. "name": "Launch Program",
  8. "program": "${workspaceFolder}/node_modules/gulp/bin/gulpfile.js",
  9. "stopOnEntry": true,
  10. "osx": {
  11. "stopOnEntry": false
  12. }
  13. }
  14. ]
  15. }

全局启动设置 Global launch configuration

VS Code 支持在你的用户设置中添加一个名为 "launch" 的对象。该启动配置将会在你的 workspaces 之间共享。比如说:

  1. "launch": {
  2. "version": "0.2.0",
  3. "configurations": [{
  4. "type": "node",
  5. "request": "launch",
  6. "name": "Launch Program",
  7. "program": "${file}"
  8. }]
  9. }

高级断点 Advanced breakpoint topics

条件断点 Conditional breakpoints

VS Code 调试功能的的强大得益于它能够设置基于表达式的条件,命中,或者两者都设置。

  • 表达式条件:当表达式的值为 true 的时候,断点将会被使用。
  • 命中:“命中”功能可以控制一个断点被命中多少次才会中断执行。是否遵守 “命中”以及表达式的确切语法在不同的调试器扩展中有所不同。

当你创建一个断点的时候,你可以添加一个条件 并且/或者 添加命中功能。你还可以使用 Add Conditional Breakpoint action 去完成上面的操作。除此之外,你还能对一个已经存在的断点进行修改(使用 Edit Condition action 也可以)。在上面两种情况下,一个有着下拉菜单的内联的文本盒子将会出现,你可以在盒子内输入表达式:
hitCount.gif

条件和命中的编辑功能也支持函数和表达式的断点。你可以从 context menu 或一个新的内联 Edit Condition action 中启动条件编辑。

一关于在 BREAKPOINTS 界面中编辑条件的例子:
breakpoints.gif

译注:我试了一下,好像不能从 BREAKPOINTS 里面编辑了….

如果一个 debugger 不支持条件断点,那么 Add Conditional Breakpoint 和 Edit Condition actions 将不会出现。

提示:这几个断点我自己试了下,没咋玩明白,所以不翻译。后面的内容,基本是对着文档翻译了一下,没怎么实验,如果有错欢迎勘误。

内联断点 Inline breakpoints

Inline breakpoints will only be hit when the execution reaches the column associated with the inline breakpoint. This is particularly useful when debugging minified code which contains multiple statements in a single line.

An inline breakpoint can be set using ⇧F9 or through the context menu during a debug session. Inline breakpoints are shown inline in the editor.

Inline breakpoints can also have conditions. Editing multiple breakpoints on a line is possible through the context menu in the editor’s left margin.

函数断点 Function breakpoints

Instead of placing breakpoints directly in source code, a debugger can support creating breakpoints by specifying a function name. This is useful in situations where source is not available but a function name is known.

A function breakpoint is created by pressing the + button in the BREAKPOINTS section header and entering the function name. Function breakpoints are shown with a red triangle in the BREAKPOINTS section.

数据断点 Data breakpoints

If a debugger supports data breakpoints, they can be set from the VARIABLES view and will get hit when the value of the underlying variable changes. Data breakpoints are shown with a red hexagon in the BREAKPOINTS section.

Debug Console REPL

表达式可以通过 Debug Console REPL(Read-Eval-Print Loop)计算出来。要打开控制台,可以点击 Debug 窗格顶部的 Debug Console 选项,或者通过命令 View: Debug Console (⇧⌘Y)。当你按下回车之后,将会得出表达式的结果,并且当你进行输入操作的时候,Debug Console REPL 会有提示。如果你需要输入多行内容,使用 Shift+enter 换行,在输入完成之后按下 Enter 计算结果。Debug Console 的输入使用当前活动的编辑器,这就意味着 Debug Console 的输入支持代码高亮,缩进,和自动闭合引用(就是输入左括号,就会出现左右两个括号),以及其他语言特性。
image.png

注意:你必须在 Debug 会话启动的情况下才能使用 Debug Console

Redirect input/output to/from the debug target

重定向输入/输出是针对调试器/运行时的,所以VS Code没有一个内置的解决方案可以适用于所有调试器。

以下是你要考虑的两种方法:

  1. 在你的终端或者命令提示下手动启动一个项目(调试的目标)进行调试,并且根据需要重定向输入/输出。确保传入合适的命令行参数给调试的目标,使得 debugger 可以 attach 到该程序。创建并且运行一个附着在调试目标上面的一个”附加 “调试配置。
  2. 如果你使用的 debugger extension 可以在 VS Code 的集成终端(或者外部的终端)上面运行调试目标,你可以尝试将shell的重定向语法(例如,”<”或”>”)作为参数传递。

集成终端:Integrated Terminal,也就是 VS Code 自带的终端。

下面是一个 launch.json 的例子:

  1. {
  2. "name": "launch program that reads a file from stdin",
  3. "type": "node",
  4. "request": "launch",
  5. "program": "program.js",
  6. "console": "integratedTerminal",
  7. "args": ["<", "in.txt"]
  8. }

这种方法要求”<“语法通过 debugger extension,最后在集成终端中未被修改。

多目标调试 Multi-target debugging

对于一些复杂的场景下,需要调用多个进程进行调试(比如说,一个服务器和一个客户端)。VS Code 支持多目标调试。

使用多目标调试很简单:当你启动了一个 debugger session 之后,再启动另一个 debugger session 就可以了。一旦第二个 debugger session 启动成功之后,VS Code 就会切换到多目标调试模式:

  • 某一个调试的会话将会独立的出现在 CALL STACK 界面的最顶层

image.png

  • debug toolbar 将会展示当前正在调试的会话(其它可用的会话在下拉菜单中)

image.png

  • 调试动作(例如,调试工具栏中的所有动作)是在活动会话上进行的。通过使用调试工具栏的下拉菜单或在CALL STACK视图中选择一个不同的元素,可以改变当前的会话。

复合启动配置 Compound launch configurations

你还可以通过使用 compound 启动配置来开启多个 debug 会话。一个复合启动配置列表有两个或多个启动配置,它们将会并行的启动。通过可选的 preLaunchTask 字段,你还可以在每一个独立的调试会话启动之前执行任务。

  1. {
  2. "version": "0.2.0",
  3. "configurations": [
  4. {
  5. "type": "node",
  6. "request": "launch",
  7. "name": "Server",
  8. "program": "${workspaceFolder}/server.js"
  9. },
  10. {
  11. "type": "node",
  12. "request": "launch",
  13. "name": "Client",
  14. "program": "${workspaceFolder}/client.js"
  15. }
  16. ],
  17. "compounds": [
  18. {
  19. "name": "Server/Client",
  20. "configurations": ["Server", "Client"],
  21. "preLaunchTask": "${defaultBuildTask}"
  22. }
  23. ]
  24. }

复合启动配置将会在启动配置下拉菜单中显示。

远程调试 Remote debugging

VS Code 自身并不支持远程调试:这应该是你目前使用的 debug extension 提供的功能,你应该在
Marketplace 中,对应插件的详情页面寻求帮助。

不过,有一个例外:VS Code 内置的 Node.js 调试器支持远程调试。详情请看 Node.js Debugging 章节。

调试某一个服务时自动的打开某一个 URI Automatically open a URI when debugging a server program

开发 Web 应用的时候,为了在 debugger 中触发服务代码(server code),通常都需要在浏览器中打开指定的 URL。VS Code 有一个内置的功能,名为“serverReadyAction”,它将会自动完成该任务。

下面是一个关于 Node.js Express 的一个简单的例子:

  1. var express = require('express');
  2. var app = express();
  3. app.get('/', function(req, res) {
  4. res.send('Hello World!');
  5. });
  6. app.listen(3000, function() {
  7. console.log('Example app listening on port 3000!');
  8. });

该程序首先为 “/” URL安装一个“Hello World” 处理器,并且开始监听 3000 端口的 HTTP 链接。该端口将在控制台中出现,然后,开发者将会在它的浏览器中输入:http://localhost:3000

serverReadyAction 功能使开发者有可能向任何启动配置添加一个结构化的属性 serverReadyAction,并选择要执行的 “行动”:

  1. {
  2. "type": "node",
  3. "request": "launch",
  4. "name": "Launch Program",
  5. "program": "${workspaceFolder}/app.js",
  6. "serverReadyAction": {
  7. "pattern": "listening on port ([0-9]+)",
  8. "uriFormat": "http://localhost:%s",
  9. "action": "openExternally"
  10. }
  11. }

这里的 pattern 属性描述了用于匹配监控端口的程序输出字符串的正则表达式。匹配端口号的模式被放在括号里,这样它就可以作为一个正则表达式捕获组来使用。在这个例子中,我们只提取了端口号,但也可以提取完整的URI。

这里的 URIFormat 属性描述了如何将端口号转换为一个 URI。第一个 %s 是一个占位符,它将被这一组配置中 pattern 字段匹配到的值替换。

然后在 VS Code之外(”外部”)用为 URI 的方案配置的标准应用程序打开所产生的 URI。

通过 Edge 或者 Chrome 触发调试 Trigger Debugging via Edge or Chrome

我们可以设置 debugWithEdge 或者 debugWithChrome 实现该操作。在该模式下,可以添加一个 webRoot 属性并传递给 Chrome 或者 Edge 会话。

为了简化一些,大多数属性是可选的,我们使用以下 fallback values:

  • pattern:"listening on.* (https?://\\S+|[0-9]+)" ,它将监听 3000 端口上最常见的信息:“listening on port 3000” 或者 “Now listening on: https://localhost:5001”
  • uriFormat:"http://localhost:%s"
  • webRoot:"${workspaceFolder}"

触发任意启动配置

在某些情况下,你可能需要为浏览器调试会话配置额外的选项——或者完全使用一个不同的调试器。你可以通过将 action 设置为 startDebugging,并将name属性设置为启动配置的名称,以便在模式匹配时启动。

命名的启动配置必须与带有 serverReadyAction 的配置在同一个文件或文件夹中。
server-ready.gif

接下来 Next steps

学习更多的关于 VS Code 的 Node.js 调试技巧,可以阅读下面的链接

  • Node.js - 描述了 Node.js 的调试器以及 VS Code。
  • TypeScript - Node.js 调试器还能调试 TypeScript

还可以观看 Node.js 调试的教程:

了解通过 VS Code 扩展对其他编程语言进行调试:

学习 VS Code 的任务(task)相关的知识:

  • Tasks - 描述了如何用Gulp、Grunt和Jake运行任务以及如何显示错误和警告。

写一个属于你的调试器插件:

  • Debugger Extension - 使用一个虚拟的例子来说明创建 VS Code 调试插件所需的步骤。

    常见问题 Common questions

    支持那些调试的场景 What are the supported debugging scenarios?

VS Code支持在Linux、macOS和Windows上对基于Node.js的应用程序进行调试,而且开箱即用。市场上的VS Code扩展支持许多其他情况。

我在运行视图下拉菜单中没有看到任何发射配置。有什么问题吗? I do not see any launch configurations in the Run view dropdown. What is wrong?

最常见的问题是,你没有设置 launch.json,或者该文件存在语法错误。另外,你可能需要打开一个文件夹,因为无文件夹调试不支持启动配置。