强制异常分类是响应式流中主动识别、区分并按类型路由异常的技术，通过onerrormap→onerrorresume构建分层恢复管道，结合可观测性与背压策略实现精准错误处理。
强制异常分类不是一种独立技术，而是指在响应式流中主动识别、区分并按类型路由异常，从而让错误恢复逻辑精准匹配故障原因。它不依赖编译器检查，而是通过操作符链中的显式判断与分发实现。
明确异常类型边界，避免泛化捕获
响应式流中，catchError 或 onErrorResume 若只用通用 Throwable 处理，会掩盖故障语义。应先用条件判断分离关键异常：
- 用
instanceof或框架提供的工具（如 Reactor 的 onErrorMap）识别IOException、TimeoutException、IllegalArgumentException等具体类型 - 对
NetworkException触发重试，对ValidationException直接降级返回默认值，对OutOfMemoryError记录并终止流 - 避免写
catch (Exception e) { ... }这类宽泛捕获——它会让业务逻辑与系统级错误混为一谈
构建分层恢复管道：从 onError 到策略分发
真正的“切入”发生在异常信号发出后、被下游消费前的中间环节。推荐使用 onErrorMap → onErrorResume 组合构建可读性强的恢复路径：
- onErrorMap 将原始异常转为带业务上下文的自定义异常（例如包装 traceId、失败输入、节点标识）
- 后续 onErrorResume 根据新异常类型选择恢复分支：网络类走
retryWhen，解析类走onErrorReturn，权限类走onErrorResumeNext(Mono.error(new UnauthorizedException())) - 示例：Flux 数据流中，JSON 解析失败时抛出
JsonParseException，经onErrorMap转为BusinessDataException.withCode("PARSE_FAILED")，再由统一处理器识别 code 字段分发处理
将异常分类结果注入背压与可观测性链路
分类不只是为了恢复，更是为了协同系统行为：
- 在 doOnError 中根据异常类型打标（如
error_type=timeout），供指标系统聚合告警 - 对瞬时异常（如超时）启用
retryBackoff，同时设置最大重试次数，防止背压积压；对确定性错误（如 404）跳过重试，直接进入 fallback 流 - 使用 MDC 或 Reactor 的 Context 传递分类标签，确保日志、链路追踪、熔断器都能基于同一维度决策
避免常见误用
强制分类不是给每个异常套一层 if-else，而是建立可维护的契约：
- 不建议在
map内部手动 throw 新异常来“制造分类”，这破坏响应式流的声明式语义 - 不要把分类逻辑放在
subscribe的 onError 回调里——此时流已终止，无法恢复 - 不推荐用全局
Hooks.onErrorDropped替代分类处理，它仅用于兜底，无法支撑业务恢复
