node 调试相关

框架

浏览数:196

2019-4-2

AD:资源代下载服务

#0 node 正确的书写方式

为了防止后面出现混乱的各种书写,先来了解一下如何正确书写 node 的名称。

下面使用来自@bitandbang 推文中的图片展示如何正确书写 node 名称。


node 名称的正确书写方式

--inspect 参数

本地开发,无论是 web 应用还是命令行工具,使用 --inspect-brk 参数启动程序,然后结合 Chrome DevTools 调试恐怕能满足大多数场景了。

具体步骤:

通过 --inspect-brk 参数启动程序,会进入调试模式。

$ `node --inspect-brk index.js`

这里使用 --inspect-brk 而非 --inspect 可保证代码第一时间断在开程序开头。如果使用后者,有可能无法进行后续操作。

打开 Chrome 新开标签页访问 chrome://inspect。不出意外会看到刚刚创建的一个调试实例,直接点击 inspect 即可启动调试。因为是 --inspect-brk 启动的,调试界面打开后会断在程序开头。后面在哪里加断点就有很大自主权了。


chrome://inspect 界面

需要注意的是,因为此时断在了程序开始,程序中其他文件可能没加载。所以无法看到。这种情况下,可事先在需要加断点的地方写上 debugger

子进程中代码的调试

另一个需要注意的地方就是子进程。对于 子进程 中的代码,是无法断点的,这是调试大多数框架及复杂程序时的痛点。

一个简单的子进程示例:

index.js

var cp = require('child_process');
var child = cp.fork('./child');

child.on('message', function(m) {
  console.log('received: ' + m);
});

child.send('Please up-case this string');

child.js

process.on('message', function(m) {
  debugger;
  // Do work  (in this case just up-case the string
  m = m.toUpperCase();

  // Pass results back to parent process
  process.send(m.toUpperCase(m));
});

这里,node --inspect-brk index.js 启动调试后,child.js 中的 debugger 并不会生效,因为它的代码在子进程中。

这也就是为什么,当你想调试 webpack 编译,恰好又用了类似 happypack 这种多进程加速编译的工具时,发现 loader 及 插件中无法断点的原因。

又比如,调试 eggjs,它也是多进程的模型,业务代码是运行在 worker 进程中的,直接通过 node 的调试参数肯定是不行的。当然框架一般会有自身配套的调试方案,你可以安装 egg 的 vscode 调试插件,或者使用 egg-scripts 来启动调试。

那是不是就无能为力了?当然不是,只是需要费劲一点。我们需要找到开启子进程的地方,在开启的时候加上调试参数。

还是上面的示例,改造主文件为如下:

var cp = require('child_process');
+var child = cp.fork('./child',[],{execArgv:['--inspect-brk']});

child.on('message', function(m) {
  console.log('received: ' + m);
});

child.send('Please up-case this string');

这样,就表示以调试模式来运行子进程中的代码,此时启动程序不要加 inspect,因为那是开启对主进程的调试,直接运行程序即可。node index.js。然后我们会在 Chrome://inspect 看到子进程已经 attach 到了调试界面。

所以,无论是通过 require('child_process'exec 还是 spawn,只需要找到开启子进程的地方,加上调试参数。

但问题是,就看你能不能正确地找到所使用的框架工具他们开启子进程的地方。

善用 npx

调试 node 模块时,特别是 npm 包,你需要手动拼出该模块的入口文件的路径,类似 node —inspect node_modules/webpack/bin/webpack.js, 但通过 npx 则不用,因为 npx 会自动在项目的 node_modules 或系统全局中寻找模块的入口文件,甚至如果本机没有安装,它还会自动搜索 registry 自动安装后执行。

以至于你在初始化一个项目时,可使用如下命令:

$ npx license mit > LICENSE
$ npx gitignore node
$ npx covgen YOUR_EMAIL_ADDRESS
$ npm init -y

即使你本地并没有安装 mitgitignorecovgen 等 npm 包。

使用 npx 时可通过 —node-arg 来传递参数给 node。因为本质上 npx 也是执行 js 文件,与直接使用 node 命令来启动文件没什么差异。—node-arg 指定的参数会透传给 node,所以,可以这样来启动一个 npm 包的调试:

$ npx —node-arg=—inspect-brk webpack

node 内建的 debugger

node 自带的 v8 调试工具,是个命令行工具。操作起来是难用,但在远端服务器上这种不能使用 Chrome Devtools 进行可视化调试的场景下,就显得很有用了,比如调试路由重定向次数过多这种瞬间发生的问题,它能将代码及时在服务器上断下来,让我们慢慢分析现场。

$ node inspect index.js


node 自带的 debugger

进入调试模式后,代码会断在开始处。可通过以下常用命令进行 debug:

  • c/cont:断续执行,类似于 Chrome DevTools 中的 F8
  • n/next:步进,类似于 Chrome DevTools 中的 F10
  • step/s: 进入,类似于 Chrome DevTools 中的 F11
  • setBreakpoint()/sb(): 设置断点。
    • 通过调用该函数可对代码设置断点。
    • 直接调用则在当前所处的行设置断点。
    • sb(line_number) 传递一个行数,对相应行设置上断点。
    • sb(file_name,line_number) 传递文件名及行数,可对非当前文件进行断点的设置。
  • clearBreakpoint: 参数与 setBreakpoint 类似,作用是清除断点。
  • breakpoints,查看设置的断点。

观察变量的值。在这种调试模式下,可通过输入 repl 进入 REPL(Read-Eval-Print-Loop) 模式来查看变量的值。


通过进入 REPL 模式查看断点处的变量值

实际使用中发现个弊端,就是打印出来的对象是不完整的,如上图。如果想查看没展示出来的属性,那就得记住属性名,然后手动点出来。你当然可以通过 JSON.stringify(variable) 将变量转字符后打出来。但 JSON 序列化可并不是处处都管用,比如 koa 中的 response, request 对象,如果尝试进行 JSON 序列化,会报 JSON 循环引用的错误。而且在这里的 REPL 环境下,不能调用 node 模块,不然就可以通过自带的 require('util').inspect(variable) 来打印了。

如果每次断在某处时,都需要查看某个变量的值,可通过设置 watcher 来更加方便地查看。

> watch('my_expression')

日志加 tail -f

服务器上面更加常用的应该还是日志加 tail,配合 -f 参数,可时实将最新的 log 输出到命令行。

$ tail -f /your/logs/log

Remote Debug

Remote Debug 这个就有点厉害了,没配置过,获取相应服务器权限设置好之后,估计没有比这个更便捷的调试服务器上代码的方式了。在有些资源或服务只在服务器环境才有的情况下,本地又不好还原场景。

相关资源