Ubuntu JS日志中错误码代表什么

在 Ubuntu 下跑 Node.js 应用时，日志里那些奇奇怪怪的错误码常常让人一头雾水。其实，它们并非天书，而是 Ja vaScript 运行时系统在跟你“通风报信”。把这些错误码读懂，问题也就解决了一半。下面逐一拆解最常见的几种类型。

1. SyntaxError（语法错误）

简单说，就是你的代码没按 JS 的语法规则来写。比如括号没配对、引号漏了、分号忘写，或者用了不合法的符号，解析器直接懵圈。
举个例子：var 1; —— 变量名不能以数字开头；function (){} —— 匿名函数如果没赋值给变量，声明时必须有名字。
解决办法：逐行检查语法，确保所有符号匹配，变量和函数命名符合规范。大部分编辑器或 IDE 会自动标红这类错误，盯着红色区域改就对了。

2. ReferenceError（引用错误）

当你试图访问一个根本不存在的变量、函数或对象属性时，就会触发这个错误。拼写错误、忘了声明、作用域不对，都是常见原因。
典型场景：a(); —— 函数 a 压根没定义；console.log(b); —— 变量 b 从未声明过。
排查思路：先确认名字有没有拼错，再用 let / const / var 把它声明了，别指望凭空使用。

3. TypeError（类型错误）

这个错误比较“任性”——你对一个数据类型干了它不支持的事。比如把数字当函数调用，或者访问一个 undefined 对象上的属性。
常见案例：123(); —— 数字不是函数；var obj = {}; obj.run(); —— 对象上没有 run 方法；"hello".toFixed(-1) —— toFixed 的参数必须是 0 到 20 的整数。
怎么防？用 typeof 或 instanceof 先确认类型，必要时用 Number()、String() 做显式转换。

4. RangeError（范围错误）

当数值或参数超出了合法范围，JS 就会抛出这个错误。比如数组长度设为负数，或者 toFixed() 传了个超出 0‑20 的参数。
典型例子：[].length = -5; —— 负数长度不合理；(12.34).toFixed(-1); —— 参数不能小于 0。
解决方式：在传入参数前加边界判断，比如 if (arr.length >= 0)，把无效值挡在门外。

5. URIError（URI 错误）

当你用 encodeURI、decodeURI、encodeURIComponent 这些函数时，如果参数里含有非法字符（比如没编码的空格或特殊符号），就会报这个错。
示例：decodeURI('%E4%B8%AD文'); —— 如果参数本应是完整 URI，但包含了未编码的中文，就可能出错。
最佳做法：传参前先检查格式，中文等特殊字符务必用 encodeURIComponent 提前编码。

6. EvalError（eval 错误，ES5+ 已弃用）

这个错误在 ES5 及更早版本中，当 eval() 收到非法参数（比如非字符串，或字符串中有语法错误）时才会抛出。如今新规范已几乎不再使用。
比如：eval(123); —— 参数得是字符串才行。
建议：直接放弃 eval，它既有安全风险又有性能问题。用 Function 构造函数或者直接调用函数来替代。

7. Node.js 特定系统错误

除了 JS 原生的错误类型，在 Ubuntu 下跑 Node 应用还可能碰到操作系统层面的错误，它们通常以系统错误码的形式出现。

• EACCES（权限不足）：试图访问没有读/写权限的文件或目录，比如 /root 目录下的配置文件。错误信息类似 Error: EACCES: permission denied, access '/root/config.json'。解决方法要么改权限（sudo chmod -R 755 /path/to/dir），要么改所有者（sudo chown -R your_user:your_group /path/to/dir）。
• EADDRINUSE（端口占用）：指定的端口已被其他进程占用，比如 3000 端口。错误示例：Error: listen EADDRINUSE: address already in use :::3000。先跑 sudo lsof -i :3000 查占用进程的 PID，再用 sudo kill -9 终止，或者换个端口（const port = 3001; app.listen(port)）。
• MODULE_NOT_FOUND（模块未找到）：Node.js 找不到你 require 的模块，要么没安装，要么路径写错了。比如 Error: Cannot find module 'express'。最简单的办法是 npm install express，或者检查 package.json 中的依赖是否完整。

错误处理最佳实践

知道了错误码的含义，还得会用正确的姿势处理它们，才能让应用更健壮。

• 用 try...catch 包裹同步代码中的危险操作：

try {
  // 可能出错的代码
  JSON.parse('invalid json');
} catch (error) {
  console.error('JSON解析错误:', error.message);
}

• 通过 process.on('uncaughtException') 捕获未处理的异常，防止应用直接崩溃：

process.on('uncaughtException', (error) => {
  console.error('未捕获异常:', error.stack);
  process.exit(1); // 优雅退出
});

• 使用成熟的日志库（比如 Winston、Bunyan）来记录错误信息，方便事后复盘和排查。

把这些错误码搞清楚了，再看日志就不会一脸懵了。每次报错都是系统在帮你定位问题，善用它们，调试效率能提升一大截。