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 定位源码。这一步虽然基础，但很多时候，问题的答案就在那里，只是容易被忽略。
