如何在谷歌浏览器中调试正在运行的Node.js后台应用程序？

调试已启动的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面板左侧文件树里，展开Filesystem，找到你的项目根目录，定位到待调试的JS文件（比如server.js）。注意，一定要打开项目目录，不是node_modules里的那些。

第二步，在行号左侧点一下，设置断点。如果代码还没加载，断点会显示成灰色的空心圆，这叫“待命状态”；一旦该文件被跑起来，断点就会变成一个实心的红点——这个细节往往被忽略，但很有用，能帮你判断调试器是否真的附着成功了。

第三步，触发服务请求。比如在浏览器访问http://localhost:3000，看看执行会不会停在断点处。如果没暂停，三步检查：断点所在的代码路径真的被执行了吗？是不是误设在被压缩、没映射的代码行？或者Node进程还处于--inspect-brk挂起状态？如果是后者，先在DevTools里按F8继续执行。

第四步，在Console面板里输入console.log('debug test')，回车。如果输出立刻出现在终端日志里，说明调试通道双向畅通——这个检查步骤很多人都跳过了，但确认一下总没坏处。