多 catch 块本身不破坏异常链，关键在于抛出方式和日志习惯；原样重抛或双参构造包装可保留堆栈，而单参 RuntimeException、finally 抛异常等操作会截断堆栈。
多 catch 块本身不破坏异常链，关键在于每个 catch 中怎么处理捕获到的异常。真正影响堆栈完整性的，是抛出方式和日志记录习惯，不是 catch 的数量或顺序。
多 catch 块不影响原始堆栈
多个 catch 块只是对同一异常做类型匹配，异常对象在 throw 时已生成完整堆栈，catch 只是“接住”，不会修改它。无论你写一个 catch 还是五个，只要没新建异常、没调用 setStackTrace() 或 initCause()，原始堆栈就原封不动。
- 每个 catch 块拿到的 e 是同一个异常实例，堆栈从最初 throw 处开始，中间不插入新帧
- 不同 catch 分支可以各自处理：有的直接重抛，有的包装为业务异常，互不干扰
- 注意 catch 顺序：子类异常必须写在父类前面，否则编译报错；但这只影响匹配逻辑，不影响堆栈
保留堆栈的两种核心做法
根据是否需要语义转换，选择对应方式：
-
原样重抛（推荐用于透传）：直接写
throw e;，不 new 新对象。方法签名需声明 throws，日志用logger.error("操作失败", e) -
包装为业务异常（推荐用于分层）：用双参构造器，把 e 当 cause 传入，例如
throw new OrderException("下单失败", e)；自定义异常类中必须调用super(message, cause)
日志和调试必须配合到位
代码里链建对了，日志打错等于白干：
立即学习“Java免费学习笔记（深入）”；
- 记录日志时，永远传整个异常对象，不要拼字符串：
logger.error("支付回调异常", ex)✅，而不是"支付回调异常: " + ex.getMessage()❌ - 确认日志配置支持全堆栈：Logback 用
%ex，Log4j2 用%throwable{full} - 调试时别只看
ex.getCause()，尤其在 try-with-resources 场景下，原始异常可能藏在ex.getSuppressed()里
避开几个典型陷阱
这些操作表面像在处理异常，实则悄悄截断堆栈：
- finally 里 throw 或 return：会覆盖 try/catch 中的异常，导致原始异常丢失
-
用
RuntimeException(e)单参构造：e 被当 message 字符串处理，不是 cause，堆栈链断裂 -
手动调
initCause()：已被包装过的异常 cause 不为 null，再调直接抛IllegalStateException -
仅打印
e.getMessage()或e.toString()：完全看不到堆栈轨迹和嵌套关系
