自定义防腐网关中捕获await错误需在async函数内用try-catch，统一拦截promise rejection，区分网络、http、业务错误，构造含message/code/cause/requestid的友好错误对象，并在网关层统一处理避免重复。
在自定义防腐网关中，用 try-catch 捕获 await 报错并转为友好提示，核心是**统一拦截 Promise rejection、区分错误类型、注入上下文信息、再抛出业务可识别的错误对象**。不是简单套个 catch 打个 alert 就完事。
捕获 await 错误必须包裹在 async 函数内
防腐网关通常封装请求逻辑（比如 fetch 或 axios 调用），这些调用本身返回 Promise。await 只能在 async 函数里用，且它遇到 rejected Promise 会直接抛出异常——这正是 try-catch 能生效的前提。
- ❌ 错误写法：在普通函数里写 await，语法报错
- ✅ 正确结构：所有含 await 的请求方法必须声明为 async，外层用 try-catch 包裹
- 示例：网关方法如 gateway.request() 内部是 async，调用方也需 async + try-catch
区分网络错误、HTTP 状态码、业务错误
不是所有报错都该显示“网络开小差”，要按错误性质分层处理：
- 网络层失败（如 DNS 失败、连接超时、离线）：底层 fetch/axios 会 reject，error.name 可能是 'TypeError' 或 'AbortError'，message 常含 "failed to fetch" 或 "network error"
- HTTP 状态码异常（如 401、403、500）：fetch 不自动 reject，需手动检查 response.ok；axios 默认对非 2xx reject，但需注意其 error.response 存在与否
- 业务错误体（如 { code: 1001, msg: "token 过期" }）：需解析响应体，结合 status 和 data.code 判断是否属于需透传的业务提示
构造可携带元信息的友好错误对象
直接 throw 字符串会导致调用方难处理；应 throw 一个带字段的 Error 实例或自定义类，包含：用户可见提示（message）、机器可读码（code）、原始错误（cause）、请求标识（requestId）。
- 推荐用 class 继承 Error，添加 extra 属性，如：new FriendlyError('登录已失效', { code: 'AUTH_EXPIRED', cause: originErr })
- 在 catch 中根据 error 类型生成不同 message：“请求超时，请检查网络” / “系统繁忙，请稍后再试” / “您暂无权限访问此功能”
- 可附加 traceId 或 timestamp，方便前端埋点或后端日志关联
在网关层统一拦截，避免每个接口重复写 try-catch
防腐网关的价值在于收敛异常处理逻辑。不要让每个业务页面自己 try-catch，而应在网关 request 方法内部完成：
- request(options) 方法内部用 try-catch 包裹 fetch/axios 调用
- 对捕获的 error 做标准化转换，再 re-throw 友好错误
- 暴露一个全局错误处理器（如 gateway.onError(fn)），供上层订阅统一提示逻辑（如 toast.show(error.message)）
- 保留原始 error.stack 或 cause 用于开发调试，但不暴露给用户
