在 Linux 上调试 Node.js，并不只有一种做法：有些问题适合直接看日志，有些更适合在断点里追调用栈，还有些则需要把模块输出按命名空间拆开看。下面按“什么场景该用什么工具”的思路重新梳理一遍，帮助你在命令行、浏览器和 IDE 之间快速做出判断，也能知道哪些工具适合新版本 Node.js，哪些更多是兼容旧环境的补充方案。

先从内置调试器开始：最省事的入口

如果你用的是较新的 Node.js 版本，最值得先上手的通常就是内置调试器。从 v6.3.0 开始，Node.js 已经提供了基于 Chrome DevTools 的调试能力，不需要额外安装工具，就能直接打开调试端口。

`--inspect` 和 `--inspect-brk` 有什么区别

这两个启动参数的差别，决定了你是“先跑起来再接管”，还是“从入口第一行就停住”。

• --inspect：正常启动程序，并开启调试端口
• --inspect-brk：启动后立即在第一行代码处暂停，适合从入口开始排查

命令如下：

node --inspect your_script.js   # 正常启动调试
node --inspect-brk your_script.js  # 第一行暂停

默认情况下，Node.js 会在 localhost:9229 打开调试端口。程序启动后，访问 chrome://inspect，就能在“Remote Target”里看到目标进程，点击“Inspect”即可接入。

接入后能做什么

连上之后，你拿到的是一套比较完整的断点调试能力：可以设置断点、查看变量、观察调用栈，也可以使用单步执行，例如 F10、F11。如果你本来就熟悉前端调试，这套体验基本没有学习门槛。

在 VSCode 中调试：适合日常开发主流程

如果你的主要工作流就在编辑器里，VSCode 往往是 Linux 下最顺手的 Node.js 调试入口。它本身已经内置支持，不需要额外插件，适合把“写代码、下断点、看变量、改完再跑”放在同一处完成。

`launch.json` 怎么配

基本步骤如下：

• 打开项目文件夹，点击左侧“Run and Debug”图标
• 选择“create a launch.json file”
• 在模板中选择“Node.js”
• 在 launch.json 里指定入口文件，例如 "program": "${workspaceFolder}/app.js"
• 建议加入 "skipFiles": ["/**"]，跳过 Node.js 内部文件

配置完成后，按 F5 即可启动调试。

它适合解决哪些问题

VSCode 的优势不在“能不能调”，而在“是否适合长期高频使用”。断点命中后，你可以直接查看变量、分析调用栈、切换执行位置，整个过程都留在 IDE 里完成。对于接口开发、脚本调试、服务端逻辑排查，这种工作流通常比在多个工具之间切换更高效。

Chrome DevTools 仍然值得单独用

虽然 Node.js 内置调试器本身就是基于 Chrome DevTools 的，但直接使用 DevTools 仍然有独立价值，尤其适合偏好图形化界面的开发者，或者需要更直观查看异步执行状态的场景。

连接方式

先用 --inspect 启动程序，再在 Chrome 中打开 chrome://inspect，找到目标脚本后点击“Inspect”即可。

异步代码为什么更适合在这里看

在 DevTools 里，常用的是“Sources”面板：你可以管理断点、查看当前作用域中的变量值，也可以在“Console”面板里直接执行片段代码验证逻辑。对 Promise、async/await 这类异步流程来说，这种可视化的上下文观察通常更直观，定位链式调用中的异常也更方便。

简单问题先用 `console.log()`，需要精确停点再上 `debugger;`

不是所有问题都值得一开始就打开完整调试器。很多时候，你只是想确认某个分支有没有执行、某个变量在关键路径上是不是变了，这种场景下，console.log() 反而是最直接的手段。

`console.log()` 适合什么场景

例如追踪执行流程、确认参数传递、比对某个中间值是否符合预期，一条日志就够了：

console.log('Reached step 1:', variable)

它的优点是成本低、插入快，尤其适合复现稳定、定位范围已经比较小的问题。

`debugger;` 怎么配合命令使用

当你已经知道“大概是哪一段代码有问题”，但还需要在特定位置停下来逐步看状态时，可以直接在代码中插入 debugger;，再用下面的命令启动：

node inspect your_script.js

程序执行到 debugger; 时会自动暂停，之后可以继续用 Chrome DevTools 或 VSCode 观察变量、单步执行。相比全程跑断点，这种方式更适合精准命中特定位置。

模块多、日志杂时，用 `debug` 库做可控输出

当项目规模变大，单纯依赖 console.log() 往往会让输出变得混乱。这个时候，debug 这类按命名空间控制日志的方式会更实用，尤其适合模块化 Node.js 项目。

安装与基本用法

安装命令按原文如下：

npm install debug --sa ve

使用示例：

const debug = require('debug')('your_script');  // 'your_script' 为命名空间
debug('Debug message: %s', variable);  // 输出格式化信息

输出结果类似 your_script Debug message: value，比无差别打印更容易筛选。

环境变量控制输出范围

它最实用的一点，是可以通过环境变量只打开你关心的命名空间：

DEBUG=your_script node your_script.js

这样可以避免无关模块刷屏。在大型项目里，这种“按模块开关日志”的方式通常比到处删改 console.log() 更省事，也更适合长期保留。

其他工具的定位：增强调试与旧环境兼容

除了内置调试器、VSCode 和 DevTools，原文还提到两类补充工具，它们更适合特定场景，而不是默认首选。

`ndb`：更偏深入分析

ndb 是基于 Chromium DevTools 的增强型调试器，适合需要进一步做内存分析、性能监测的情况。

npm install -g ndb
ndb your_script.js

如果你排查的已经不是普通逻辑错误，而是性能瓶颈、内存占用异常，这类工具的价值会更明显。

`node-inspector`：主要面向旧版本 Node.js

node-inspector 属于传统方案，更适用于旧版本 Node.js：

npm install -g node-inspector
node --debug your_script.js

启动后监听 8080 端口，访问 http://localhost:8080/debugport=9229 即可调试。对于新版本 Node.js，优先级通常还是低于内置调试器和 VSCode，这一点需要先判断运行环境再决定。

怎么选：按问题复杂度匹配工具

如果只是确认流程和变量，console.log() 往往最快；如果需要精准停在某一行，debugger; 加 node inspect 更合适；如果你想长期稳定地做断点调试，VSCode 和 Chrome DevTools 是主力选择；当项目模块很多、日志噪声过大时，再引入 debug 会更有价值。至于 ndb 和 node-inspector，一个偏深入分析，一个偏旧环境兼容，适合作为补充，而不是所有项目的默认起点。