在 Ubuntu 中分析 JS 错误日志的实用流程
一 明确日志来源与定位日志文件
- 前端 JS：优先查看浏览器开发者工具 Console 与 Network（快捷键 F12 或 Ctrl+Shift+I），关注报错信息、堆栈与响应状态码。
- Node.js 后端：常见位置为项目目录下的 logs/ 或应用配置指定的文件；若由 systemd 托管，用 journalctl -u your-service-name 查看；若使用 PM2，用 pm2 logs 实时查看。
- 系统层面：/var/log/（如 syslog）可能包含服务启动、崩溃与权限相关线索。
- 不确定位置时，先查应用文档/配置；必要时用 grep -R “ERROR” /path/to/app 在项目中搜索关键字。
二 命令行快速筛选与解析
- 实时跟踪与关键字过滤：
- 文件日志：tail -f app.log | grep -i “error|exception|fail”
- systemd 服务：journalctl -u your-service -f -S “10 minutes ago”
- PM2 应用：pm2 logs your-app --lines 200 | grep -i error
- 文本处理：
- 提取时间与级别：awk ‘{print $1, $2, $3, $4}’ app.log
- 清洗与抽取片段：sed -n ‘/ERROR/p’ app.log
- JSON 日志（安装 jq：sudo apt-get install jq）：
- 按错误字段筛选：jq ‘select(.level==“error”) | .message’ app.log
- 展开堆栈：jq -r ‘.stack’ app.log
- 进阶：将筛选、解析写成脚本并用 cron 定时运行，便于沉淀分析规则。
三 Node.js 常见错误模式与处理
- 弃用警告（DeprecationWarning）：如 Buffer() 已弃用，升级 Node.js 与依赖，按官方建议改用 Buffer.alloc()/Buffer.from()。
- 未处理的 Promise 拒绝（UnhandledPromiseRejectionWarning）：为所有 Promise 加 .catch() 或使用 try/catch；临时全局监听：
- process.on(“unhandledRejection”, (reason) => console.error(reason));
- 监听器泄漏（MaxListenersExceededWarning）：避免重复添加监听器，必要时 emitter.setMaxListeners(n) 或 removeListener。
- 内存不足（JavaScript heap out of memory）：短期提升堆上限 node --max-old-space-size=4096 app.js；长期用 clinic/heapdump 定位泄漏并优化数据结构与缓存策略。
四 前端与 Node.js 的调试手段
- 前端：在 Sources 面板设置断点、单步执行、观察作用域与网络响应；配合 Console 的报错与 Network 的状态码/响应体定位问题。
- Node.js：使用 node --inspect-brk app.js，在 Chrome 访问 chrome://inspect 进行远程调试；结合日志级别与堆栈定位模块与行号。
五 监控与长期治理
- 日志集中化：小规模可用 ELK Stack（Elasticsearch/Logstash/Kibana） 或 Graylog 做采集、检索与可视化；大规模建议引入结构化日志与采样策略。
- 运行监控：用 Prometheus + Grafana 采集指标并配置告警（如错误率、延迟、内存），与日志联动排查。
- 第三方库问题：关注日志中的 错误级别、错误消息、堆栈跟踪，核对 package.json 与 npm list 的版本，查阅库文档与社区；必要时回退或升级版本。
