在 Ubuntu 上运行 JavaScript 时，日志里最有价值的信息通常不是整段堆栈，而是最前面的错误类型。只要先分清它到底是变量未定义、类型不对，还是语法本身写错，排查路径就会立刻收窄，后续再结合报错行号和上下文代码，定位问题会快很多。
Ubuntu 下 JavaScript 日志里常见错误码是什么意思
JavaScript 在 Ubuntu 环境中运行，无论是浏览器调试、Node.js 脚本还是服务端任务，日志里出现的错误类型基本都遵循同一套规则。下面这些名称看起来像“错误码”，本质上是 JavaScript 引擎给出的错误类别，用来提示问题属于哪一类。
ReferenceError：变量或函数没有找到
ReferenceError 表示你正在使用某个变量、常量或函数，但它并没有被正确声明。最常见的情况有两种：一是名字拼错了，二是作用域不对，当前代码访问不到它。
例如，你在函数内部调用了一个根本不存在的变量，或者以为某个值是全局可用的，实际并不是，就会触发这类错误。遇到它时，优先检查变量名拼写，以及声明位置是否覆盖到当前执行范围。
TypeError：值存在，但操作方式不对
TypeError 的意思不是“找不到”，而是“找到了，但不能这么用”。例如把一个不是函数的值当函数调用，或者对当前数据类型执行不支持的操作，都会报这个错误。
常见场景包括：把字符串、对象、数字混用时没有做类型判断；某个变量本应是函数，结果实际拿到的是 undefined、字符串或对象；又或者调用链中某一层返回值和预期不一致。看到 TypeError，就该先核对变量当前到底是什么类型。
SyntaxError：代码在解析阶段就出错了
SyntaxError 属于最直接的一类问题，说明代码本身不符合 JavaScript 语法规则。常见原因包括括号缺失、引号未闭合、逗号位置错误，或者结构没有写完整。
这类错误往往在代码真正运行前就会被发现，也就是说解释器还没执行到业务逻辑，就已经因为语法不合法而中断。排查时不要先怀疑运行结果，而是回到报错附近逐字符检查。
RangeError：数值或调用深度超出允许范围
RangeError 表示某个值超出了合理范围。典型情况包括递归调用层级过深导致栈溢出，或者传入了不被接受的数值范围。
原文中提到数组索引越界也可能被理解为“范围问题”，但在实际排查中，更值得优先关注的是递归过深、参数异常或构造对象时传入了非法长度这类场景。看到这类日志，要先确认输入值和调用深度是否失控。
不太常见但也会出现的几类错误
EvalError：与 eval() 相关的历史型错误
EvalError 在现代 JavaScript 中已经很少见。它原本用于表示 eval() 使用过程中出现的异常情况，但现在很多相关问题已经会落到其他更具体的错误类型上。
虽然规范中仍然保留了这个名称，但日常开发里看到它的概率并不高。如果日志里真的出现了，通常就该回头检查是否使用了 eval()，以及传入内容是否合法。
URIError：URI 编码或解码参数非法
URIError 常见于 encodeURI()、decodeURI() 以及相关方法的调用过程。它说明你传入的 URI 字符串中包含非法内容，或者编码格式本身有问题。
这类报错在处理外部输入、拼接链接、解析回调参数时更容易出现。排查重点不是业务逻辑，而是字符串内容是否完整、是否被重复编码，或者是否混入了不合法字符。
Error：没有落到更具体分类的通用错误
Error 是最常见的兜底类型。当问题不属于前面那些更明确的类别，或者开发者主动使用 throw new Error() 抛出异常时，日志里就会显示这一类。
它本身提供的信息比较宽泛，所以要结合完整报错消息一起看。比如是运行时逻辑异常、资源占用问题，还是业务代码主动抛错，通常都要从 Error 后面的具体文案和堆栈里判断。
看到日志后该怎么判断和处理
实际排查时，不必一上来就把整段日志全部读完。更高效的顺序通常是先看错误类型，再看报错发生的行号，最后回到对应代码位置检查上下文。
如果是 ReferenceError，优先核对变量声明和作用域；如果是 TypeError，重点确认当前值的真实类型；如果是 SyntaxError，就直接检查语法结构是否完整；如果是 RangeError 或 URIError，则应优先怀疑输入值是否越界或格式非法。
大多数问题都能通过这套顺序快速缩小范围。实在无法定位时，再去查文档、翻社区讨论或补充调试输出，效率通常会比从头盲猜高得多。
