多catch块顺序应按业务语义分层而非继承关系，子类异常必须前置以防编译错误和逻辑失效，兜底catch需置于末尾并保留原始堆栈，慎用multi-catch以免掩盖处理差异。
多catch块的顺序不是语法限制的简单排序，而是业务意图的显性表达——它决定了哪类问题该被优先识别、如何响应、是否需要补偿动作。
按业务语义分层，而非仅看继承关系
即使两个异常没有父子继承关系，只要它们在业务中代表不同严重程度或处理路径，就应按实际影响排序。比如支付场景中：
- PromotionInvalidException（优惠券失效）→ 返回明确提示，引导用户更换券
- InventoryShortageException（库存不足）→ 触发降级逻辑，尝试分配替代商品
- RemoteServiceException（下游服务不可用）→ 记录告警，返回“稍后重试”
这种顺序不依赖类结构，而是由用户感知、系统可恢复性、运营干预成本共同决定。
子类必须前置，否则编译失败且逻辑失效
当异常存在继承关系时（如AccessDeniedException是IOException的子类），子类catch必须写在父类之前。否则：
立即学习“Java免费学习笔记（深入）”；
- 编译器直接报错：“unreachable catch block”
- 即使侥幸通过（如使用反射绕过检查），运行时也无法进入子类分支
- 真实发生的AccessDeniedException会被IOException捕获，丢失权限语义
兜底catch只放末尾，且必须保留原始堆栈
把catch(Exception e)放在最前，等于提前关闭所有精准处理通道。正确做法是：
- 仅作为最后一道防线，写在所有具体异常之后
- 日志记录必须用log.error("unexpected error", e)，不能只打e.getMessage()
- 避免直接吞掉异常；可根据上下文包装为统一错误响应，但要保留cause链
慎用multi-catch，除非响应逻辑完全一致
写成catch(IOException | SQLException e)看似简洁，但隐含风险：
- 两类异常可能需不同用户提示（“文件读取失败” vs “订单数据异常”）
- 补偿动作不同（重试文件操作 vs 回滚数据库事务）
- 后续若需区分，只能靠instanceof硬判断，破坏类型安全
真正适合合并的场景极少，例如：网络层所有连接类异常都触发熔断，且无需差异化处理。
