规范的async错误分类方案需按来源分层：传输层（网络中断等）、协议层（HTTP非2xx等）、业务层（结构化code如AUTH_EXPIRED）、解析校验层（JSON失败等）；统一结构化返回{error,result,meta}，error含type和code；按响应动作分静默恢复、用户感知、流程阻断、系统告警四类；配套API封装、全局监听、入口管控及上报路由机制保障落地。
设计一套规范的 async 错误分类方案，核心不是给错误“贴标签”，而是建立可区分、可响应、可追踪的错误语义体系。关键在于让每类错误有明确的归属层、处理动作和传播边界，避免混用网络层超时和业务逻辑缺失这类本质不同的问题。
按错误来源分层归类
错误必须与它的产生位置强绑定，否则无法决定谁该处理、怎么恢复：
- 传输层错误：网络中断、DNS 失败、TLS 握手失败、HTTP 连接超时。特点是无响应体、无状态码，通常不可重试或需指数退避。
- 协议层错误：HTTP 状态码非 2xx（如 408、429、502、504），或 WebSocket 关闭码（1006、1011）。属于服务可达但通信异常，多数可重试或降级。
-
业务层错误：服务端返回的结构化错误（如
{"code": "AUTH_EXPIRED", "message": "登录已过期"}）。含语义，需前端主动识别并跳转/提示/清缓存，不计入技术错误日志主通道。 - 解析与校验错误：JSON 解析失败、字段缺失、类型不符、schema 校验不通过。属前端可控范围，应捕获后打点上报，保留原始响应体便于定位。
定义标准化错误结构
所有异步调用结果（无论成功或失败）统一包装为结构化对象，消除“抛出与否”的歧义：
- 推荐形态：
{ error: Error | null, result: any, meta: { timestamp, url, correlationId } } - error 字段必须包含
type（如'network'/'http'/'business'/'parse'）和code（如'ECONNABORTED'或'AUTH_INVALID'） - 避免用 message 字符串做判断逻辑，所有分支决策基于 type + code 组合
按响应动作划分错误等级
同一类错误在不同上下文可能触发不同行为，需结合场景分级：
- 可静默恢复型：如列表页某条数据拉取失败，用本地缓存或空占位，不上报也不提示
- 用户感知型：如提交表单失败，展示友好提示，并提供重试按钮；需记录操作上下文（如表单字段值哈希）
- 流程阻断型：如鉴权失败、支付签名无效，立即中断当前流程，跳转至指定页面或弹窗引导
- 系统告警型：如连续 3 次解析失败、未知 error.code 出现，触发前端监控告警，附带堆栈与原始 payload
配套机制保障分类落地
分类方案若无基础设施支撑，极易退化为文档摆设：
- API 请求封装层自动识别 HTTP 状态码并映射到对应
type/code，不把 401 当作普通 error 抛出 - 全局
unhandledrejection监听器仅用于兜底，记录未被结构化包装的漏网错误，并标记为type: 'unknown' - 所有异步入口（如组件
useEffect、页面onLoad）只做顶层状态控制（loading/error/ui），不内联具体错误处理逻辑 - 错误上报 SDK 支持按
type和code自动路由到不同告警通道（如 business 类走业务告警群，network 类走运维告警群）
