try-catch 不存在“捕获深度”机制，其异常匹配是沿调用栈线性查找首个匹配的 catch 块；防腐层依赖分层拦截与语义归一，而非嵌套 try-catch，应通过协议层拦截、适配层转换和业务层兜底实现多级异构错误对齐。
这个说法存在概念混淆。“try-catch 的捕获深度特性”并不是一个真实存在的编程机制——try-catch 本身没有“深度”属性，它只按代码执行路径和异常抛出位置进行线性匹配，不支持“多级异构错误的智能数据对齐”这类抽象工程目标。
所谓“捕获深度”，实际是嵌套结构的视觉错觉
你看到的“外层 catch NullPointerException、内层 catch ArithmeticException”，只是代码块嵌套带来的层级感。JVM 并不按“第几层”去匹配异常，而是：
- 从抛出点开始，沿调用栈向上查找第一个能匹配该异常类型的
catch块 - 嵌套 try 块只是提供了多个就近的捕获点，不是“深度优先搜索”
- 一旦某层 catch 捕获成功，外层同类型异常处理器就不再触发（除非显式
throw）
统一接口防腐层的关键不在 try-catch 嵌套，而在分层拦截与语义归一
真正支撑防腐层的是结构化设计，而非语法嵌套：
- 协议层拦截：HTTP 状态码、gRPC status code、MQ 消息头字段等，在网关或客户端 SDK 中提前识别并转为标准错误码
-
适配层转换：对接第三方系统时，把
TimeoutException、SocketException、FeignException统一封装为RemoteServiceUnavailableException -
业务层兜底：在 Service 方法入口用
@ExceptionHandler或 AOP 统一捕获，将所有底层异常映射到领域错误枚举（如ORDER_CREATE_FAILED），附带 traceId、用户ID、原始错误摘要
多级异构错误对齐，靠的是上下文+映射规则，不是 try 块嵌套
例如处理支付回调失败场景：
- 支付宝返回
"ACQ.TRADE_HAS_CLOSE"→ 映射为PAYMENT_CLOSED - 微信返回
ERR_CODE: "ORDERPAID"→ 映射为PAYMENT_SUCCESS_DUPLICATE - 内部 DB 抛出
SQLIntegrityConstraintViolationException→ 映射为DUPLICATE_ORDER_SUBMIT
这些映射逻辑应写在统一异常处理器或策略工厂里，而不是靠三层 try-catch 分别抓取再手工 if-else 对齐。
更简洁可靠的替代方案
放弃“利用捕获深度”的思路，改用明确、可测试、易维护的方式：
- 定义错误契约：每个外部系统返回错误都对应一个
ExternalErrorMapping配置项 - 使用责任链模式：按优先级顺序尝试匹配各系统错误码，命中即返回标准错误对象
- 日志中保留原始错误（脱敏后）+ 标准错误码 + 业务上下文，便于追踪与统计
- 避免在业务方法里写多层 try-catch，它们会掩盖调用关系、阻碍单元测试、增加维护成本
