应子类化exception（java）或error（前端），为业务错误赋予可识别、可路由、可聚合的语义标签，并通过统一抛出、分类捕获、上下文注入与监控联动实现可观测性闭环。
直接用 Error 的子类化来构建异常监控体系，关键不在“造新类”，而在于**让不同业务场景的错误拥有可识别、可路由、可聚合的语义标签**。Java 和前端（如鸿蒙、Web）都支持自定义 Error 子类，但真正起作用的是你如何设计继承结构、如何在抛出时注入上下文、以及后续如何按类型做分类捕获与上报。
明确 Error 子类的定位：不是替代 RuntimeException，而是承载业务语义
Java 中 Error 表示 JVM 层严重故障（如 OutOfMemoryError），不建议也不应被子类化用于业务逻辑。真正该子类化的是 Exception，尤其是自定义的业务异常类——它们应继承自 Exception 或其子类（如 RuntimeException）。鸿蒙或前端 JS 环境中，Error 是可安全扩展的顶层构造函数，适合定义领域级错误类型。
- Java 后端：定义如
OrderValidationException、PaymentTimeoutException，继承自RuntimeException（非检查型，避免污染接口） - 鸿蒙/JS 前端：定义如
NetworkTimeoutError、PermissionDeniedError，继承自Error，并添加code、category、traceId等自有字段 - 避免“为子类而子类”：每个子类必须对应一个明确的监控维度（如「支付失败」「权限拒绝」「网络超时」），否则失去分类价值
统一抛出与捕获入口：让子类错误可被精准识别和路由
子类本身不会自动被监控系统识别，必须配合统一的抛出约定和全局捕获策略。
- 所有业务异常统一通过封装方法抛出，例如：
throw BizErrors.paymentFailed("余额不足", orderId);，内部返回预设的子类实例 - 后端 Spring Boot 使用
@ControllerAdvice按异常类型分组处理，为每种子类映射唯一错误码、HTTP 状态码和日志级别 - 鸿蒙前端在
AbilityStage.onCreate()中注册errorManager.on('error', ...)，并在回调中用err instanceof NetworkTimeoutError判断类型，分流至不同日志通道 - 前端 Web 环境使用
window.addEventListener('error')+unhandledrejection，对自定义 Error 实例提取err.name（如 "NetworkTimeoutError"）作为分类主键
增强子类携带上下文：让一次异常自带可追踪元数据
仅靠类名分类不够，真实排查需要关联请求、用户、设备、版本等信息。子类化要支持动态注入运行时上下文。
- 在自定义 Error 构造函数中接收并保存
traceId、userId、pageName、osVersion等字段，并重写toString()或提供toReportData()方法输出结构化对象 - 鸿蒙示例：
new NetworkTimeoutError("支付网关响应超时", { traceId: "t-abc123", api: "/v1/pay" }) - Java 示例：在自定义异常中增加
private final Map<string object> context = new HashMap();</string>，通过 builder 模式设置 - 监控 SDK 上报时，自动提取这些字段，与指标（Metrics）、链路（Tracing）、日志（Logging）三者打通，实现「看到错误 → 关联链路 → 查看日志」闭环
配套建立分类聚合看板：让子类真正驱动运营动作
子类化最终要服务于可观测性落地。没有下游消费，就只是代码层面的装饰。
- 在 Sentry、SkyWalking 或自建平台中，按
error.name（JS）或exception.class（Java）创建告警规则，例如：「PaymentTimeoutError5 分钟内超过 10 次触发企业微信告警」 - 在 Grafana 看板中，用 Prometheus 指标
app_exception_total{type="PaymentTimeoutError"}绘制趋势图，对比版本发布前后变化 - 日志系统（如 ELK）中，对
error.category: "payment"做聚合分析，识别高频失败环节（如「签约服务超时占比 72%」） - 定期扫描未被监控覆盖的子类（如新增了
BiometricAuthError但没配置告警），形成异常治理清单
