捕获深度特性本质是分层拦截与错误映射能力，而非try-catch固有属性；需在接入层、解析校验层、业务语义层分别捕获网络错误、解析异常、伪成功业务码，并统一转化为结构化错误模型。
这个问题听起来很“架构感”，但核心其实很实在：所谓“捕获深度特性”并不是 try-catch 的固有机制，而是一种对异常传播路径和分层拦截能力的合理利用。在统一接口防腐层（anti-corruption layer）中，目标不是堆砌多层 try-catch，而是让不同来源、不同语义、不同层级的错误（比如网关超时、下游服务返回的业务码、JSON 解析失败、空指针）能被识别、归类、映射为前端可理解的一致错误模型。
明确“捕获深度”的真实含义
try-catch 本身没有“深度”属性，但它在调用栈中的位置决定了它能捕获到哪一层抛出的异常：
- 外层 catch 能捕获内层函数抛出的异常（只要没被中间层吞掉）
- 异步操作（如 Promise、callback）必须显式进入执行上下文，否则不会落入同步 try 块
- Java/C# 中，异常会沿调用栈向上冒泡，直到遇到匹配的 catch 或终止程序；JS 中则只冒泡同步异常，异步需靠 await/.catch() 拦截
防腐层中错误智能对齐的三层实践
不靠嵌套层数，而靠职责分层：
-
接入层拦截（最外）：捕获网络级、协议级错误（如 fetch 失败、超时、CORS），统一转为
NetworkError并附带 traceId 和请求快照 -
解析与校验层（居中）：在 await res.json()、JSON.parse()、DTO 映射等处设独立 try-catch，把 SyntaxError、ValidationError、NullPointerException 等转为
ParseError或InvalidResponseError，保留原始响应体片段（脱敏后） -
业务语义层（最内）：由下游服务返回的 HTTP 200 + { "code": "USER_NOT_FOUND" } 这类“伪成功”，需主动检查 code 字段并 throw 新的
BusinessCodeError(code, message)，再由上层 catch 统一映射为标准错误码（如 40401）
避免“伪深度”陷阱
常见反模式要警惕：
- 把所有 await 都裹进同一 try 块——无法区分是网络失败还是解析失败，更无法记录各阶段耗时
- 用
catch (Exception e)吞掉一切，再靠e.getClass().getName()if-else 分支——丧失类型安全，且掩盖了异常本意 - 在防腐层里重新 throw 原始异常（如 SQLException）——暴露技术细节，违反防腐原则
真正起作用的是结构化错误建模
对齐的关键不在“捕获多深”，而在“转化多准”。建议定义一个轻量错误契约：
- errorType：枚举值（NETWORK / PARSE / VALIDATION / BUSINESS / UNKNOWN）
- errorCode：业务系统定义的标准码（如 AUTH_TOKEN_EXPIRED）
- traceId + timestamp + endpoint：用于问题定位
- userVisibleMessage：前端可直接展示的文案（非 stackTrace）
每一层 catch 只负责填充其中部分字段，最终由防腐层出口统一组装并记录日志。
