Nodejs 调试方法

   nodejs内部提供一个debug机制，可以让程序进入debug模式，供开发者一步一步分析代码发现问题。   共有3中启动参数可以让程序进入debug模式，假设我们要对app.js进行调试。   node debug app.js   node --debug app.js   node --debug-brk app.js   3种模式在调试形式上有一定区别。   node debug app.js   1.这种方式启动程序，程序会进入debug模式，并运行到启动文件的第1行就停止，等待开发者下发往下走的命令。   2.这种方式启动程序，直接在当前cmd中进入调试模式。   node --debug app.js   1.这种方式启动程序，程序会进入debug模式，并运行完所有代码。这种启动方式往往用于程序启动的过程中不需要调试，通过触发时间进入回调函数的情况，比如在某个http请求中打上断点，等待客户端访问后进入断点。   2.这种方式启动程序，会开启一个TCP的端口监听，在本cmd中不进入调试模式，需要另外开启终端用node debug 命令连接调试端口。命令为 node debug localhost debug端口或者  node debug p node进程id。   node --debug-brk app.js   1.这种方式启动程序，程序会进入debug模式，但是不会运行代码，直到有一个终端连接到了debug端口，才开始执行代码，并在第1行进入断点。   2.这种方式启动程序，会开启一个TCP的端口监听，在本cmd中不进入调试模式，需要另外开启终端用node debug 命令连接调试端口。   进入debug模式后，可以通过一些命令来设置断点、取消断点以及控制程序执行流程。Nodejs支持js原生的调试，可通过debugger来下断点。通过console.log(var)来显示变量的值。也可以在debug下输入repl再来查看变量的值。   node.js调试命令

命令 功能 run 执行脚本,在第一行暂停 restart 重新执行脚本 cont,c 继续执行,直到遇到下一个断点 next, n 单步执行 step, s 单步执行并进入函数 out, o 从函数中步出 setBreakpoint(), sb() 当前行设置断点 setBreakpoint(‘f()’), sb(…) 在函数f的第一行设置断点 setBreakpoint(‘script.js’, 20), sb(…) 在 script.js 的第20行设置断点 clearBreakpoint, cb(…) 清除所有断点 cbacktrace, bt 显示当前的调用栈 list(10) 显示当前执行到的前后10行代码 watch(expr) 把表达式 expr 加入监视列表 unwatch(expr) 把表达式 expr 从监视列表移除 watchers 显示监视列表中所有的表达式和值 repl 在当前上下文打开即时求值环境 kill 终止当前执行的脚本 scripts 显示当前已加载的所有脚本 version 显示v8版本

nodejs中有supervisor这个热部署组件，supervisor插件帮我们监视文件改动，自动重启服务器，supervisor是node.js的一个包，安装起来很简单，使用npm的安装命令就可以，因为我们需要在控制台运行，所以需要安装在全局环境中。
npm install -g supervisor

   这样我们就可以使用supervisor启动脚本了   supervisor app   我们也可以通过node-inspector来调试，首先运行node-inspector，再运行node debug app.js。通过浏览器打开就能相关的调试。   一个关于nodejs比较好的技术文章，其地址为：http://technosophos.com/2011/10/28/nodejs-debugging-built-debugger.html，内容如下：   The HTTP version of the app worked, but the commandline version did not. What went wrong? It was hard to say. The application simply hung, unresponsive. Try/catch and event handlers didn't find anything wrong, and my typical console.log() approach wasn't cutting it, either. I need to fire up Node.js's command line debugger.   This is a short tutorial explaining how to use the debugger that comes built-in to Node.js. It explains how to use the command line debugger to set breakpoints , step through the code, and analyze the debugging output. By the time you're done reading, you should be able to quickly debug your own code.   The Basics   Node has a built-in debugger   It can be executed using node debug your_scriptfile.js   In your app, you can set breakpoints using debugger;   Now let's look at each step of debugging.... <!--break-->   Set Some Breakpoints   A breakpoint is a place in your code where you want to be able to "fast forward" to inside of the debugger. If you don't use a breakpoint, you will have to step through the code one step at a time. And by "the code", I mean not only your own code, but Node.js's code, as well as the code of any packages you are using.   In your script, at places near where you think the problem is occurring, you will want to place some breakpoints:

    debugger; // LOOK AT ME! I'm a breakpoint.    this.emit('error', error);  }

   A breakpoint is set in the code using the special keyword debugger. As I understand it, this is a fixture of the V8 engine, not necessarily of Node.js.   You can set as many debugger; breaks as you want.   Starting Up The Debugger   To start the debugger, run your command using node's debug argument: node debug your_scriptfile.js. You will find yourself at a cursor that shows debug >. You can type help to see the debugger's scant help info, or you can type run to run the code.

  debug> run  debugger listening on port 5858connecting... ok  breakpoint #1 in #<Object>.[anonymous](exports=#<Object>, require=function require(path) {      return Module._load(path, self);    }, module=#<Module>, __filename=/somefile.js:7

   At any time, you can type quit to quit the debugger.   Now you have a view into the currently-executing code. The output shows you the exact line of code that is currently executing (and what file it is found in). Let's see how we can navigate.   Listing Code and Generating a Trace   The first thing you will likely want to do is get your bearings. Where, exactly, are we in the code? to do this, type list. This command prints a formatted and line-numbered segment of code:

  debug> list   1 /*!   2  * This is a command-line client built with Pronto.   3  *   4  * Run it with `node apikey.js`. By default, it will print help text.   5  */   6   => var pronto = require('pronto');   8 var mongo = require('pronto-mongodb');   9 var AddAPIKey = require('../lib/commands/addapikey');  10 var Closure = require('pronto/lib/commands/Closure');  11 var Settings = require('../lib/util/settings.js');

   Here e can see the context of the current line of code. So now we can see where, in the code, we are. The line marked => is the line currently being executed, and the surrounding lines give context. But what about the execution stack? How to I get stack trace information?   I can get this information using the backtrace command:

  debug> backtrace  #0 module.js:355:19  #1 apikey.js:7:14  #2 Module._compile module.js:411:26  #3 Module._extensions module.js:417:10  #4 Module.load module.js:343:31  #5 Module._load module.js:302:12  #6 Module.runMain module.js:430:10  #7 startup.processNextTick.process._tickCallback node.js:126:26

   While most of the stack above is just core Node.js libraries, as we get into our problems, stack traces will provide valuable insight into potential problems by revealing what chain of events led to the current code being executed.   The next thing we want to do is jump to that first breakpoint we set.   Going to Your Breakpoint   When you start a debugger and execute the run command, the debugger begins at the first line of the script. Most of the time, this is far away from the section we want to debug. Earlier we set a breakpoint using debugger;. Now we want to jump to that breakpoint.   To do this, we can use the command continue, which tells the debugger to continue until it hits either a breakpoint or the end of the script. In short, it fast forwards to the next stopping point.

  debug> continue  debug> break in #<Object>.[anonymous](exports=#<Object>, require=function require(path) {      return Module._load(path, self);    }, module=#<Module>, .../myfile.js:157  debugger;  ^

   As we can see from the marker on the last line, we have hit a debugger; statement. Again, we can get our bearings with list:

  debug> list  151   console.log('error caught in router');  152   console.log(err);  153 })  154   155 //console.log(baseCxt)  156 var cmd = process.argv[2] || 'help';  ==> debugger;  158 // Run the command.  159 try {  160  router.handleRequest(cmd, baseCxt);   161 }

   This gives us an idea of the context. Now I need to navigate around. In the debugger, you can only step forward. continue is a fast forward. But we have two more modest methods.   STEP and NEXT   Now we will look at two navigation commands. step is short for step into this one, and next is short for move to the next one. Sometimes they do the same thing (when there is nothing to step into).   Right now, we are on the debugger; statement. We can't "step into" it (it's not a function or control structure; there's nothing to inspect). So we will go to the next instruction:

  debug> next;  break in #<Object>.[anonymous](exports=#<Object>, require=function require(path) {      return Module._load(path, self);    }, module=#<Module>, foo.js:160   router.handleRequest(cmd, baseCxt);           ^  debug> list  154   155 //console.log(baseCxt)  156 var cmd = process.argv[2] || 'help';  157 debugger;  158 // Run the command.  159 try {  ==>  router.handleRequest(cmd, baseCxt);   161 }  162 catch (e) {  163   console.log('Caught by try/catch')  164   console.log(err);

   next moved us forward to the next statement (try/catch is ignored). Now we're on the line router.handleRequest(cmd, baseCxt);. We can either go over that (next) and move to the next statement, or we can step into it, and see what is happening in the handleRequest() function.   next: Go to the next line. (Move over)   step: Step into the details of the current line. (Move down)   We want to see what is happening inside of handleRequest(), so we will step into it:

  debug> step  break in #<Router>.handleRequest(request=get, cxt=#<Context>, tainted=undefined), /router.js:71    request = this.resolveRequest(request);                   ^  debug> list   65  * - reroute   66  *   67  * @param string request   68  * @param pronto.Context cxt (optional)   69  */   70 Router.prototype.handleRequest = function(request, cxt, tainted) {  ==>   request = this.resolveRequest(request);   72      73   var spec = this.registry.getRequestSpec(request);   74   if (spec == undefined || spec == null) {   75     var err = new Error('Request not found');  debug>

   From the output above, we can see that we're not in a different file (router.js) looking at the handleRequest() function.   From here, we could step and next our way through the code.   Using 'print' to See the Contents of a Variable   Finally, there is one more useful debugging trick that can help a great deal: At any point during debugging, you can print the content of any variable is scope. For example, when we look at the listing from before, it might be unclear what this has in it at the moment it is used on line 71. So we can print it and see:

  debug> print this  { _events: '#<Object>', registry: '#<Registry>', resolver: 'null' }

   print produces output roughly in the same format as a call to console.log(). Big objects can have substantial output, but the one above is pretty minimal. And we could further inspect the this.registry object with print, too:

  debug> print this.registry  { config: '#<Object>', currentParamName: 'null', currentIndex: '0', help: '#<Object>', currentRequestName: '--help' }

   Combining breakpoints, step, next, list, backtrace, and print, we can learn all about what is happening in our application during runtime.   Working with the commandline debugger may not be pretty, but it is a functional way to figure out what's happening behind the scenes. For those hard-to-find bugs, it's a great tool to know.

一些关于nodejs调试的文档：
http://www.barretlee.com/blog/2015/10/07/debug-nodejs-in-command-line/
http://i5ting.github.io/node-debug-tutorial/
http://www.cnblogs.com/tzyy/p/5028348.html
Nodejs官方的调试文档：https://nodejs.org/api/debugger.html