自定义 Error 子类能显著提升异步错误处理的可读性与语义化，通过语义化命名（如 ValidationError、ApiTimeoutError）、携带结构化上下文（statusCode、field 等）、分层包装错误及配合全局处理器精准分流，实现错误“会说话”。
自定义 Error 子类能显著提升异步错误处理的可读性与语义化，核心在于让错误“会说话”——明确告诉开发者：错在哪一层、属于哪一类、该怎么响应。
用语义化名称区分错误场景
把模糊的 Error 或 TypeError 替换为带业务含义的类名，比如：
-
ValidationError：数据校验失败（如字段缺失、格式不对） -
ApiTimeoutError：HTTP 请求超时 -
NotFoundError：API 返回 404 或数据库查无结果 -
AuthError：认证失败（token 过期、权限不足）
这样在 catch 块里就能直接用 instanceof 判断类型，避免靠 error.message.includes('timeout') 这类脆弱匹配。
携带结构化上下文信息
除了默认的 message 和 stack，子类可添加业务相关属性：
-
statusCode: number（用于 HTTP 错误） -
field: string（指出哪个字段校验失败） -
originalError: Error（包装原始异常，保留根源） -
retryable: boolean（标识是否适合重试）
例如：throw new ApiTimeoutError('User fetch timed out', { url: '/api/users', timeoutMs: 5000 }); —— 日志和监控系统能直接提取关键字段，无需解析 message 字符串。
统一错误传播与捕获逻辑
在 async/await 链中，自定义错误不会被自动“翻译”，但你可以让它自然穿透各层：
- 服务层抛出
DbConnectionError - 业务层捕获后包装为
UserServiceError，并附加操作上下文（如用户 ID） - 控制器层根据子类类型决定响应状态码和提示文案
这种分层包装让错误既保留原始原因，又带上当前调用语境，调试时一眼看清“从哪来、经过哪、现在在哪”。
配合全局错误处理器精准分流
利用 window.addEventListener('unhandledrejection') 或 Express 的错误中间件，按子类做差异化处理：
-
instanceof ValidationError→ 返回 400，前端高亮表单字段 -
instanceof AuthError→ 清除 token，跳转登录页 -
instanceof ApiTimeoutError→ 触发重试或展示加载降级 UI
比判断 error.name === 'Error' 或正则匹配 message 更可靠、更易维护。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
