Ubuntu Node.js如何进行错误处理

Node.js 中的错误处理，说到底是每个开发者迟早要面对的核心课题。在 Ubuntu 环境下跑 Node.js 应用，如果连错误都接不住，调试起来会相当头疼。下面这几条经过验证的路径，基本覆盖了日常开发中绝大多数的异常场景。

回调函数中的错误优先约定

这是 Node.js 最经典的错误处理模式，尤其在早期版本中随处可见。约定很简单：回调函数的第一个参数永远留给错误对象，如果一切正常，这个参数就是 null 或 undefined，后续参数才是真实数据。这种设计让错误处理和正常逻辑天然耦合在一起。

const fs = require('fs');
fs.readFile('file.txt', 'utf8', (err, data) => {
  if (err) {
    console.error('读取文件时发生错误:', err);
    return;
  }
  console.log('文件内容:', data);
});

注意看：一旦发生错误，立刻打印并 return，避免继续执行后面的逻辑。这个模式虽然古老，但对底层 I/O 操作仍然非常实用。

通过事件监听器捕获错误

Node.js 很多模块（比如流、HTTP 服务）本身就是 EventEmitter 的实例。它们会在内部发射 error 事件，如果没监听，程序会直接崩溃。因此，对这类对象养成“先监听错误，再处理数据”的习惯至关重要。

const fs = require('fs');
const readable = fs.createReadStream('file.txt');
readable.on('error', (err) => {
  console.error('读取文件时发生错误:', err);
});
readable.on('data', (chunk) => {
  console.log('文件内容:', chunk);
});

这里的关键顺序：先绑定 error 事件，再绑定 data 事件。如果反过来，错误发生时可能因为事件队列顺序而漏掉。

Promise 与 async/await 的优雅之路

现代 Node.js 开发中，Promise 和 async/await 已经成为首选方案。它们让异步代码的写法更像同步，错误处理也归入 try/catch 结构，直观且不易遗漏。

const fs = require('fs').promises;
async function readFileAsync() {
  try {
    const data = await fs.readFile('file.txt', 'utf8');
    console.log('文件内容:', data);
  } catch (err) {
    console.error('读取文件时发生错误:', err);
  }
}
readFileAsync();

注意：这里用的是 fs.promises，而不是默认的 fs 模块。很多内置模块都提供了 Promise 版本，能节省大量包装代码。

全局错误处理：最后的安全网

无论怎么小心，总会有漏网之鱼——未捕获的异常、未处理的 Promise 拒绝。Node.js 提供了两个全局事件监听器，可以兜住这些异常。

// 处理未捕获的异常
process.on('uncaughtException', (err) => {
  console.error('捕获到未处理的异常:', err);
});

// 处理未处理的 Promise 拒绝
process.on('unhandledRejection', (reason, promise) => {
  console.error('捕获到未处理的Promise拒绝:', reason);
});

不过，必须警惕的是：全局错误处理不是万能药。过度依赖它，程序可能进入不确定状态（比如文件描述符未释放、内存泄漏）。正确的用法是把它当作“最后的防线”——一旦触发，记录日志、优雅退出或重启进程。局部错误处理（回调、事件监听、async/await）才是日常代码中的主力。

总结一下：不同类型的场景对应不同的处理方式。回调函数适合遗留代码和底层 libuv 操作；事件监听器是流和服务的标配；async/await 能写出最干净的现代代码；全局处理器只作为兜底机制。把这四层用到位，你的 Node.js 应用在 Ubuntu 上就会稳得多。