直接继承Error并精准添加业务字段是构建自定义错误类的核心，需显式设置name、调用super(message)，按需添加field/statusCode/code等语义化字段，确保instanceof识别与JSON安全序列化，并在throw/catch中闭环使用。

直接继承 Error 并补充业务字段，是编写清晰直观自定义错误类的核心方法。关键不在“多”，而在“准”——每个字段都应明确回答“错在哪、为什么错、怎么定位”。

继承 Error 并固定 name 属性

必须显式设置 this.name，否则实例的 name 会默认为 "Error"，失去类型区分意义。构造函数中调用 super(message) 确保堆栈和 message 正常，再覆盖 name：

• class ValidationError extends Error { constructor(message) { super(message); this.name = 'ValidationError'; } }
• 避免只写 this.name = ... 却漏掉 super()，否则 stack 属性为空，调试时无法追踪源头

按需添加语义化业务字段

字段要服务于真实处理逻辑，不是堆砌信息。常见且实用的有：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• field：标出校验失败的具体字段名，如 throw new ValidationError('不能为空', 'email')
• statusCode：对接 HTTP 响应，便于统一转成 API 错误响应，如 this.statusCode = 400
• code：定义内部错误码（字符串），比如 'USER_NOT_FOUND'，比数字更易维护和国际化
• 不建议加冗余字段如 timestamp 或 user，这些应在上报或日志层注入，而非污染错误类本身

确保 instanceof 和 JSON 兼容性

自定义错误要能被自然识别，也要能安全序列化：

立即学习“Java免费学习笔记（深入）”；

• 用 err instanceof ValidationError 可靠判断类型，前提是正确继承 Error（不是仅复制属性）
• 原生 Error 实例无法被 JSON.stringify 完整序列化（stack 和 name 会丢失），如需上报，应手动提取关键字段：{ name: err.name, message: err.message, field: err.field, code: err.code }
• 不要重写 toJSON 方法试图自动序列化，容易引发循环引用或掩盖问题

配合 throw 和 try-catch 形成闭环

自定义错误的价值体现在使用方式里：

• 在业务校验点直接 throw new ValidationError(...)，而不是先 console.error 再 throw new Error(...)
• 上层 catch 块可按类型分流处理：if (err instanceof ValidationError) { showFieldError(err.field, err.message); }
• 避免在 catch 中把自定义错误又包装成普通 Error，那样就丢掉了所有业务上下文