直接继承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 兼容性
自定义错误要能被自然识别，也要能安全序列化：
- 用
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，那样就丢掉了所有业务上下文
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
