调试已启动的 Node.js 服务，不少同学会陷入一个误区：直接打开 DevTools，断点却毫无反应。 为什么？因为必须先连上那个进程，才能抓住它。连不上，变量、调用栈、单步执行统统与你无关。 这本质是前后端调试逻辑的分水岭。很多人踩过坑，所以我先把它说清楚： **必须用调试器主动 attach 到正在监听 `--inspect` 的 Node 进程，断点才会真正生效。**

确认 Node.js 进程已启用调试监听

打开终端，输入 ps aux | grep node，查看进程的启动命令里是否有 --inspect 字样。 没有？说明它根本没开调试模式——这是第一道门。门没开，后续所有操作都是白费。 如果看到类似 node --inspect=0.0.0.0:9229 server.js 或 node --inspect-brk server.js 的输出，恭喜，调试已启用。 **注意记下端口号**，比如 9229、9876 等。后面连接时必须一模一样，少一位都不行。 另外注意：如果端口绑定的是 127.0.0.1，则只能本机连接。想远程调试，启动时需显式写成 --inspect=0.0.0.0:9229，并且防火墙要放开该端口。

在 Chrome 中发现并接入运行中的 Node.js 实例

在 Chrome 地址栏输入 chrome://inspect 并回车。 过几秒，底部的“Remote Target”区域就会自动列出正在监听的 Node 进程。 如果没有，三步排查： - 进程是否真的在监听？ - Chrome 和 Node 是否在同一台机器上？ - Chrome 的实验性功能是否关闭？——新版 Chrome 默认支持，无需调整 flags。 找到对应的进程名（通常是脚本文件名，如 server.js），点击右侧的 Inspect 链接。 一个新 DevTools 窗口弹出，专门调试 Node 后端。**记住：这不是调试前端页面，而是后端进程。**

通过 WebStorm 配置 Attach 方式连接（推荐团队协作场景）

再介绍一个团队协作中更顺手的工具：WebStorm。

方法一：内置运行配置向导

打开 WebStorm → Run → Edit Configurations → 点击左上角的 + → 选择 Attach to Node.js/Chrome。 然后填写两项： - **主机**：Node 在本机填 localhost；在 Docker 容器或远程服务器填对应 IP（如 192.168.1.100）。 - **端口**：与进程启动时 --inspect 指定的端口号严格一致（如 9229）。 **务必勾选 Auto-reconnect（自动重新连接）**。用 nodemon 做热重载时，进程每重启一次，WebStorm 会自动重新连接，无需手动操作。

方法二：从终端日志复制连接地址

在启动 Node 的终端中，找到类似 Debugger listening on ws://127.0.0.1:9229/xxxx-xxxx-xxxx 的行。 其中的 127.0.0.1:9229 就是主机和端口，直接粘贴进配置即可。 **注意：手输端口容易出错，宁可复制，不要手动输入。**

验证调试已生效并设置首个断点

设置断点、验证效果——这一步才是真刀真枪的实操。

第一步：在 DevTools 的 Sources 面板找到文件

在 Sources 面板左侧文件树中，展开 Filesystem，找到项目根目录，定位到待调试的 JS 文件（如 server.js）。 注意：一定要打开项目目录，而不是 node_modules 里的文件。

第二步：设置断点

在行号左侧点击，设置断点。 - 如果代码尚未加载，断点显示为灰色空心圆——这是“待命状态”。 - 一旦该文件被运行，断点会变成实心红点。 **这个细节常被忽略，但很有用**：能帮你判断调试器是否真的附着成功。

第三步：触发服务请求

例如在浏览器访问 http://localhost:3000，观察执行是否会停在断点处。 如果没暂停，三步检查： 1. 断点所在代码路径是否真的被执行？ 2. 是否误设在了被压缩、未映射的代码行？ 3. Node 进程是否仍处于 --inspect-brk 挂起状态？如果是，先在 DevTools 按 F8 继续执行。

第四步：在 Console 面板测试调试通道

输入 console.log('debug test') 并回车。 如果输出立即出现在终端日志中，说明调试通道双向畅通。 **这个检查步骤很多人跳过，但确认一下总没坏处。**