别让 throw 沦为甩锅工具：构建可靠的 JS 自定义异常体系

项目跑着跑着崩了，控制台弹出一行 Uncaught TypeError: undefined is not a function。你在堆栈里翻找半天，只知道哪里错了，却不知道业务上为什么错。这种体验相信不少人都经历过。很多开发者习惯直接 throw '网络错误' 或 throw new Error('出问题了')，这种做法在简单脚本里能凑合，一旦进入复杂工程，就会变成维护噩梦。

抛出的异常不应该只是报一个数字代码，它应该是可被程序理解和处理的信号。

从字符串抛出到类继承

直接使用字符串抛出虽然语法允许，但会丢失堆栈追踪信息，调试时几乎等于盲打。更规范的做法是继承内置的 Error 类。

class BizError extends Error {
  constructor(message, code) {
    super(message);
    this.name = 'BizError';
    this.code = code; // 业务错误码，用于前端映射友好提示
    Error.captureStackTrace(this, BizError);
  }
}

这里有个关键细节：务必在子类构造函数中调用 super()。这不仅是为了初始化父类属性，更重要的是在现代 V8 引擎中，它能确保捕获正确的 stack 回溯路径。如果你发现堆栈信息总是指向某个中间层而不是出错点，很可能就是没处理好这个继承关系。

赋予异常“身份标识”

仅仅有消息不够，业务系统里更需要区分错误的类型。比如库存不足、权限拦截、参数非法，它们对应的用户反馈完全不同。在自定义错误类中增加 code 字段是一个极佳的实践。

当后端返回特定状态码（如 403）时，前端不需要硬解析文本，而是通过 err.code === 'PERMISSION_DENIED' 来精准匹配文案。这种结构化的错误处理，比单纯靠 message 字符串匹配要稳定得多，也能避免因为文案微调导致的全局搜索替换风险。

全局兜底与日志上报

定义了好的异常类，如果不在全局层面统一捕获，依然会白忙活。建议在入口文件设置全局错误监听。

window.onerror = (msg, url, line, col, err) => {
  if (err instanceof BizError) {
    // 记录业务逻辑错误，不影响页面继续渲染
    logReport(err); 
    return true; 
  }
  // 其他未知错误才做熔断或提示
};

这里要注意区分预期内的业务异常和非预期的崩溃。对于前者，应该静默记录并给出友好提示；对于后者，才是真正需要阻断流程的情况。不要把所有 catch 里的错误都打印成红字警告，那只会让运维人员忽略真正的隐患。

拒绝吞掉堆栈

有时候为了兼容性或封装方便，我们会写这样的代码：

try {
  riskyOperation();
} catch (e) {
  throw new Error('操作失败'); // 错误！堆栈已断
}

这种重写操作会切断原始堆栈链，让你再也找不到最初的报错位置。保留原错误堆栈的标准写法是：

try {
  riskyOperation();
} catch (e) {
  throw new Error('操作失败', { cause: e }); // ES 新特性，或通过手动拼接
}

确保每一层传递都带着“案底”，这对定位深层嵌套调用的 bug 至关重要。

写在最后

完善的异常体系不是炫技，而是对用户体验负责。当错误发生时，我们提供的不应是一个冰冷的技术堆栈，而是一个清晰的故障说明和处理建议。把 throw 从随意的情绪发泄变成严谨的信号传递，你的项目稳定性自然会迈上一个台阶。