如何使用Ubuntu JS日志进行调试

Ubuntu 环境下使用 JS 日志进行调试的实用流程

调试这事儿，说难不难，说简单也不简单。很多时候，问题就藏在那几行日志里，关键看你知不知道去哪里找、怎么看。这里梳理了一套在Ubuntu下用JS日志排查问题的流程，都是实战中反复验证过的方法，可以直接拿来用。

一 定位日志来源与输出方式

首先得搞清楚，你调试的JS跑在哪儿。场景不同，日志的“藏身之处”也完全不同。

如果是前端JS，打开浏览器的开发者工具，Console面板就是主战场；如果是Node.js后端，那就要看应用日志文件、systemd日志（用journalctl查看），或者进程管理工具（比如PM2）的日志。

常见的日志位置和工具如下：

• 应用自定义日志：通常在项目目录下的 logs/ 文件夹，或者你自定义的日志路径（比如 /var/log/yourapp.log）。
• 系统日志：/var/log/syslog 或 /var/log/messages，有时候系统层面的报错会留在这里。
• systemd 服务日志：用 journalctl -u your-service 来查看。
• PM2 托管应用：直接 pm2 logs your-app 就能看到实时输出。

经验表明，在Node.js项目中，更推荐的做法是使用结构化日志库（比如winston），同时输出到文件和控制台。这样做的好处是：文件日志方便回溯，控制台输出方便实时查看，两边都不耽误。

二 快速查看与检索日志

日志找到了，怎么高效地看才是关键。实际操作中，往往会发现日志文件动辄几百行甚至更多，逐行翻看效率太低。

实时查看：

• 文件日志：tail -f logs/app.log，这是最常用的命令，没有之一。
• systemd 服务：journalctl -u your-node-service -f，加上 -f 参数就能持续跟踪输出。
• PM2 应用：pm2 logs your-app -f，同理。

关键词过滤与高亮：光看还不够，得会“抓”。

• 过滤错误：tail -f logs/app.log | grep -i "error"，大小写通吃。
• 精准匹配（正则）：grep -E '^[[0-9]{4}-[0-9]{2}-[0-9]{2}' app.log，比如按日期格式匹配。

时间范围检索：systemd 支持这个功能，非常实用。journalctl -u your-service --since "10 minutes ago"，只看过去10分钟的日志，迅速定位突发问题。

组合使用 grep + awk/sed 做字段抽取与统计，是进阶技巧。比如统计特定错误出现的频率，或者提取出所有报错的时间戳，这对于分析高频错误和异常模式来说，效率会高出一大截。

三 常见错误模式与处理

有些错误可以说是“老朋友”了，隔三差五就会遇到。把这几种常见情况的处理方法记熟，能省下不少排查时间。

EADDRINUSE（端口被占用）：说白了就是你想用的端口已经被别的进程占了。

• 查占用：sudo lsof -i :3000，看看是哪个进程占了3000端口。
• 释放：sudo kill -9 ，注意别杀错了进程。

Module not found（依赖缺失）：大概率是 package.json 里没装全，或者路径写错了。直接用 npm install <模块名> 补上就行。

SyntaxError（语法错误）：检查对应文件和行号，仔细看看是不是少了括号、引号没闭合、或者写了不该写的字符。修正后重启服务。

Node.js 运行时警告：这几种警告出现频率很高，值得特别注意。

• DeprecarationWarning：说明正在用一个即将废弃的API。解决方案是升级Node.js和相关依赖，替换掉废弃写法。比如用 Buffer.alloc 替代 new Buffer。
• UnhandledPromiseRejectionWarning：Promise 抛出的错误没有被捕获。最直接的办法：给每个 Promise 加上 .catch() 或 try/catch。同时可以监听全局的 process.on('unhandledRejection') 事件，做个兜底处理。
• MaxListenersExceededWarning：意味着某个事件绑定了太多监听器，可能存在内存泄漏。检查代码，必要时可以用 emitter.setMaxListeners() 合理调大阈值。不过最根本的办法还是找到泄漏点。

四 提升日志可读性与可观测性

日志不光要能看，还得“看得清楚”，最好能自动分析和报警。这里有几个提升方向。

结构化日志：用 winston 输出 JSON 格式的日志，按 level（error/warn/info/debug） 分流到不同文件。比如 error.log 只记录错误，combined.log 记录所有级别的日志。这样一来，检索和聚合会方便很多。

进程管理：用 PM2 统一托管应用，顺便解决日志轮转的问题。比如 pm2 start app.js --name api && pm2 logs api，一行命令就能搞定启动和日志查看。

集中化与监控：如果项目规模比较大，手工查日志显然不现实。搭建 ELK（Elasticsearch/Logstash/Kibana） 实现日志集中管理和全文检索，或者接入 Sentry/Bugsnag 做错误追踪。再配合 Prometheus + Grafana 监控关键指标并设置告警，基本就能做到“问题还没感知到，告警已经先到了”。

五 最小化调试示例

光说不练不够，这里给出一套可以直接上手的代码示例。

用 winston 记录日志到文件，并在应用关键路径记录信息。

• 安装：npm install winston
• 配置与输出：

const winston = require('winston');
const logger = winston.createLogger({
  level: 'info',
  format: winston.format.json(),
  transports: [
    new winston.transports.File({ filename: 'error.log', level: 'error' }),
    new winston.transports.File({ filename: 'combined.log' })
  ]
});
logger.info('服务启动', { port: 3000 });
logger.error('数据库连接失败', { err: err.message });

观察与过滤：

• 实时查看：tail -f combined.log | grep -i "error"
• 如果是 systemd 运行：journalctl -u yourapp -f
• 如果是 PM2 运行：pm2 logs yourapp -f

前端 JS 问题：打开浏览器开发者工具 → Console/Network 面板，看报错信息和请求响应状态，结合 source map 定位源码。这一步虽然基础，但很多时候，问题的答案就在那里，只是容易被忽略。