如何在Debian下调试JS代码

调试 Ja vaScript 这件事，说到底就是找到问题出在哪一步。在 Debian 环境下，不管是写 Node.js 后端，还是调前端页面，有不少顺手的方法可以帮你快速定位 bug。下面就把这些年积累的调试手段过一遍。

一 环境准备

先把基础环境搭好。在 Debian 上装 Node.js 和 npm 非常直接：

• sudo apt update
• sudo apt install nodejs npm

建议用 Node.js 14 以上的版本，调试体验会好不少。装完验证一下：node -v 和 npm -v 能看到版本号就没问题。

这里要说明一点：后面讲的方法覆盖两类场景——Node.js 后端 和 前端浏览器。Node 端主要靠 --inspect / --inspect-brk 配合 Chrome DevTools；前端就直接用浏览器开发者工具。

二 Node.js 调试

先说 Node.js 这边，主要有四种调试方式，每种都有它的适用场景。

方式一 使用 Chrome DevTools 调试

这是最直观的方式。启动应用时加上参数：

• 普通启动：node --inspect app.js
• 首行暂停（方便一启动就设断点）：node --inspect-brk app.js

然后在 Chrome 浏览器地址栏输入 chrome://inspect，在 Remote Target 区域里找到你的应用，点 inspect 就能打开 DevTools。断点、调用栈、变量值一览无余。

方式二 使用 VS Code 调试

如果你习惯用 VS Code，可以在项目根目录创建 .vscode/launch.json，配置如下：

{
  “version”: “0.2.0”,
  “configurations”: [
    {
      “type”: “node”,
      “request”: “launch”,
      “name”: “Launch Program”,
      “program”: “${workspaceFolder}/app.js”
    }
  ]
}

之后在调试面板选择 Launch Program 启动，设置断点、观察变量都很方便。

方式三 使用 nodemon 热重载 + 调试

开发阶段经常改代码，nodemon 加上调试模式能省不少事。先全局安装：

npm install -g nodemon

然后在项目目录创建 nodemon.json：

{
  “watch”: [“src”],
  “exec”: “node --inspect-brk src/app.js”
}

启动就很简单了：nodemon。代码一改，自动重启并进入调试模式。

方式四 命令行调试器 node inspect

如果你偏好命令行，Node 自带的调试器也能用：

node inspect app.js

常用命令：n（下一步）、c（继续）、s（步入）、o（跳出）、repl（进入交互环境）、setBreakpoint / sb（设置断点）、watch（监视表达式）。

需要额外提醒的是：如果要远程调试，得确保 9229 端口可达，然后在目标机器的 chrome://inspect 里就能看到了。

三 前端与浏览器调试

前端调试相比后端要直观一些，主要是借助浏览器的开发者工具。

本地页面

在 Debian 上用 Chrome 或 Firefox 打开页面，按 F12 进入开发者工具。Console 面板看报错，Sources 面板设断点单步执行，是最常用的套路。

远程/无头 Chrome 调试（服务器场景）

有时候需要在服务器上调试无头浏览器，可以用远程调试端口：

google-chrome --disable-gpu --headless --no-sandbox --remote-debugging-address=0.0.0.0 --remote-debugging-port=5333

然后在本地或跳板机的 Chrome 里打开 chrome://inspect，点 Configure，添加 服务器IP:5333，就能在 Remote Target 中 inspect 目标页面了。

移动端/USB 调试

如果需要在手机上调试页面，在开发机启动 Chrome 的远程调试端口，然后在 chrome://inspect/#devices 里启用“发现 USB 设备”和“端口转发”，就能连接手机上的页面进行调试。

四 日志与问题定位技巧

除了断点调试，日志也是定位问题的利器。关键在于怎么让日志有条理、不杂乱。

结构化日志

用 debug 模块可以按命名空间输出日志，按需开启不同模块的日志，非常灵活。

• 安装：npm install debug
• 使用：

const debug = require('debug')('myapp');
debug('Hello, %s', 'world');

• 运行：DEBUG=myapp node app.js（也可以用 DEBUG=myapp:* 开启子命名空间）

严格模式与类型检查

在代码头部加上 ‘use strict’，能避免不少拼写错误和变量泄漏问题。如果项目复杂，可以考虑引入 TypeScript 或 Flow，编译期就能发现类型错误。

测试驱动定位

写单元测试或集成测试，用 Jest、Mocha 或 Jasmine。快速回归验证，比手动反复测代码有效率得多。比如：

npm install --sa ve-dev jest

然后在 package.json 里加一条脚本：“test”: “jest”。

五 常见问题与排查

最后把实际调试中容易踩的坑列出来，省去不必要的折腾。

看不到 Remote Target： 确认应用确实以 --inspect 或 --inspect-brk 启动，并且 9229 端口没有被防火墙拦截。用 --inspect-brk 的好处是应用启动后会在第一行暂停，等待 DevTools 连接。

远程服务器无法 inspect： 服务器启动时必须加上 --remote-debugging-address=0.0.0.0 才能监听所有网络接口。然后在本地 Chrome 的 chrome://inspect 中 Configure 里填写 服务器IP:端口。云服务器别忘了开放安全组或防火墙端口。

无头环境无法打开 DevTools： 无头模式没有图形界面，所以不能在服务器上直接操作开发者工具。解决方案就是前面提到的——开启远程调试端口，用本地 DevTools 连上去。

断点不生效或代码未加载： 很多前端项目用了 Webpack 或 Vite 打包，如果 source map 配置不对，调试时看到的会是编译后的代码。确认打包工具的 source map 配置正确，并在 Sources 面板检查实际加载的文件路径映射。