自定义错误类型能精准区分错误并匹配处理策略。如TimeoutError重试、AuthError跳转登录、BusinessError展示用户、ParseError上报监控；还支持日志归因、字段扩展、类型安全和根因定位。
因为能更精准地区分错误类型，让处理逻辑更有针对性，而不是所有异常都用同一个兜底方式应对。
错误分类决定处理策略
网络请求失败、数据校验不通过、权限不足、超时——这些错误的成因和应对方式完全不同。如果统一用 Error，所有异常都走同一个 catch 分支，就容易出现“一错全杀”或“该重试没重试、该提示用户没提示”的问题。
- 网络超时（
TimeoutError）：适合自动重试 1–2 次 - 401/403 响应（
AuthError）：应跳转登录页，清空本地凭证 - 后端返回的业务错误（
BusinessError）：提取message直接展示给用户 - JSON 解析失败（
ParseError）：说明接口异常，需上报监控，不提示用户
便于调试与日志归因
日志系统看到 AuthError: Token expired，就能立刻定位是鉴权环节出问题；而泛化的 Error: Request failed 需要翻查上下文、比对时间点、再人工推测，排查成本高得多。
- 自定义子类可自带字段，比如
status、errorCode、requestId - 前端监控平台可按子类名聚合错误率，快速发现某类问题是否集中爆发
支持类型安全与编辑器智能提示
在 TypeScript 项目中，定义 class ValidationError extends Error 后，你可以在 catch 块里用 instanceof 精准判断，并获得对应属性的类型提示：
try {
await submitForm();
} catch (err) {
if (err instanceof ValidationError) {
// 编辑器知道 err 有 .field 和 .message 属性
showFieldError(err.field, err.message);
}
}
避免掩盖真正问题
直接 throw new Error('Failed') 是模糊的，相当于把病历写成“不舒服”。而 throw new NetworkError('Failed to fetch /api/user', { cause: e }) 明确了层级（网络层）、位置（/api/user）、根因（底层 error），后续无论是重试逻辑、降级方案，还是服务端协同排查，都有明确依据。
